Исследование применимости гибких методологий для территориально распределенных проектов по разработке программного обеспечения (на примере компании ЗАО "ЛАНИТ")

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], но и помочь руководи6телю управлять потоком работ и выявлять «узкие места».

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 - 5.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 календарь в каждой части проектной команды.

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

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

o Velocity;

o WIP;

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

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

o Post Sprint Defect Arrival;

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

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

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 дня (было решено увеличить длину спринта).

Заключение

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

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

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

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

Таким образом, внедрение разработанных предложений позволило решить выявленные проблемы.

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

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

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

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

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

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

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

agile коммуникация метрика программный

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

1. Масленников В.В., Крылов В.Г. Процессно-стоимостное управление бизнесом // Сfin.ru: Корпоративный менеджмент, библиотека управления.

2. ABM Moniruzzaman, Dr Syed Akhter Hossain Comparative Study on Agile software development methodologies // Систем. требования: Adobe Reader.

3. Что такое Agile? // AgileDays - сайт, посвященный конференции AgileDays'12.

4. Основополагающие принципы Agile-манифеста // Agilemanifesto.org: сайт, содержащий agile-манифет.

5. 8^th annual State of Agile survey // VersionOne: сайт платформы по управлению проектами, использующих гибкие методологии. Систем. требования: Adobe Reader.

6. Vemulapalli H. Five Agile Challenges for Distributed Teams // Agile Connection: сообщество TechWell.

7. Shiralige A. Distributed Agile: How to Address People and Communication Challenges // Agile Buddha: сообщество, посвященное agile.

8. Вольфсон Б. Гибкие методологии разработки, 2012 г. // Систем. требования: Adobe Reader.

9. Sandeep J. Working with Agile in a Distributed Team Environment // MSDN Magazine: журнал компании Microsoft для разработчиков.

10. Mannaro K. Adopting Agile Methodologies in Distributed Software Development. Систем. требования: Adobe Reader.

11. Ladas C. Scrumban - Essays on Kanban Systems for Lean Software Development // Lean Software Engineering: сообщество специалистов по программной инженерии, практикующих методологию Lean.

12. Sutherland J., Viktorov A., Blount J. Distributed Scrum: Agile Project Management with Outsourced Development Teams. Систем. требования: Adobe Reader.

13. Официальный сайт конференции AgileDays

14. Anup Hande, Sunita Suralkar, P.M.Chawan Distributed Software Project Development // Систем. требования: Adobe Reader.

15. Balasubramaniam Ramesh, Lan Cao, Kannan Mohan, Peng Xu Сan distributed software development be agile? // Систем. требования: Adobe Reader.

16. Dragusha C. Managing Virtual Teams Guidelines to Effective Leadership // Систем. требования: Adobe Reader.

17. Suprika Vasudeva Shrivastava Distributed Agile Software Development // Систем. требования: Adobe Reader.

18. Communication on Agile Software Teams // Agile Modeling: портал, посвященный внедрению гибких методологий: 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: сайт, посвященный играм для проектных команд.

21. Cohn M. Distributed Teams: Build Trust through Early Progress // Mountain Goat Software: блог, посвященный тренингам по скрам.

22. Use Ambassadors to Improve Communication with your Offshore Scrum Teams // Payton Consulting: официальный сайт компании Payton Consulting.

23. Pichler R. Common Product Owner Traps // Scrum Alliance: сообщество agile специалистов.

24. Grazi V. Implementing Kanban in Practice // InfoQ: портал о профессиональной разработке программного обеспечения.

25. Bradley C. Kanban vs. Scrum: Kanban is not for Software Development, but Scrum is //The Scrum Crazy Blog: блог коуча Bradley C.

26. Kircher M., Jain P., Corsaro A., Levine D. Distributed eXtreme Programming // Систем. требования: Adobe Reader.

27. Shore J. The Art of Agile Development // Сайт книги The Art of Agile.

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

29. Коберн А., Вильямс Л. Парное программирование: преимущества и недостатки // Блог о разработке программного обеспечения.

30. Palmer S.R. An Introduction to Feature-Driven Development // DZone: сообщество для технических специалистов.

31. Palmer S.R., Felsing J.M. Practical Guide to Feature-Driven Development // InformIT: сообщество издателей, специализирующихся на информационных технологиях.

32. Allue X.Q. Visual Management for Agile Teams // XQA: блог, посвященный практикам визуального менеджмента.

33. Highsmith J. Velocity is Killing Agility! // Jim Highsmith: сайт консультанта ThoughtWorks, Inc.

34. Голдштайн И. Scrum метрики и отчеты - измерьте результаты управления // Agile Russia: сайт, посвященный различным аспектам гибкой разработки программного обеспечения.

35. Факторович С. Методологии разработки ПО, agile и scrum. Часть 2 // Систем. требования: Adobe Reader.

36. Hanoulle Y. How to work with a whiteboard (kanban board) with a distributed team? // Yves Hanoulle: сайт коуча Yves Hanoulle.

37. Silver Catalyst Features // Tools for agile: сайт, посвященный программному продукту Silver Catalyst.

38. Deemer P. Distributed Scrum Primer // Good Agile: сертифицированные скрам тренинги.

Приложение 1

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

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

НАЗНАЧЕНИЕ

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

ОГРАНИЧЕНИЯ

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

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

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

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

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

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

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

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

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

b. Аналитики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 9. Этапы формирование команды в Scrum

Этап	Быстрый переход	Средний переход	Долгий переход
Формирование	0-ый спринт	2-ой спринт	2-ой спринт
Бурление	1-ый спринт	4-ый спринт	6-ой спринт
Нормализация	1-ый спринт	6-ой спринт	10-ый спринт
Функционирование	2-ой спринт	8-ой спринт	16-ый спринт
Расформирование	Завершение проекта

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

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

Наиболее популярные обучающие игры по гибким методологиям:

· agile часы - участники выбирают картинки и слова, которыми можно наиболее точно описать позиции agile манифеста;

· Scrumble - настольная игра, имитирующая процессы разработки в рамках Scrum;

· битва ретроспектив - дает представление о том, как можно и нужно проводить ретроспективы;

· и другие.

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

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

Одной из рекомендованных специалистами практик является рассказывание детских историй со взрослой точки зрения Once upon a time - Agile FairyTales . Данный метод с помощью простых рассказов позволяет понять, как участники проектной команды подходят к решению проблем. Наиболее полезен данный метод: при формировании новых команд, для установления доверительных отношений внутри команды, научить участников команды смело выражать свои мысли, в качестве триггера для саморазвития.

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

Игры для мозгового штурма

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

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

Игры для анализа предметной области

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

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

Игры для управления требованиями

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

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

3. ВНУТРИПРОЕКТНЫЕ КОММУНИКАЦИИ ПРОЕКТА

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

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

· ФИО сотрудника

· Должность или роль на проекте

· Логин Skype

· Адрес электронной почты

· Контактный телефон (рабочий и сотовый)

· Филиал, в котором работает участник команды, если человек работает из дома, то указывается город

· Часовой пояс, в котором работает участник команды

· Часы доступности участника команды.

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

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

Должны быть выстроены прочные горизонтальные коммуникации между всеми участниками проектной команды. Скрам-мастер должен находиться вместе с основной частью команды, а в удаленной части команды назначается помощник скрам-мастера, который будет передавать информацию о деятельности своего подразделения. Хочется отметить, что помощник скрам-мастера не заменяет самого скрам-мастера, а является только дополнительным (страхующим) источником информации и не избавляет скрам-мастера от необходимости общаться с удаленной частью команды (см. Рисунок 11). Роль помощника скрам-мастера обычно совмещается с другой ролью из команды разработки и предлагается наиболее опытным специалистам.

Рисунок 11. Схема взаимодействия проектной команды

4. УПРАВЛЕНИЕ СРОКАМИ И СОДЕРЖАНИЕМ ПРОЕКТА

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

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

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

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

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

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

Рисунок 12. Доска для визуализации работы над задачами

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

Все работы должны фиксироваться в трекинговой системе (Jira, TFS) - это позволит отслеживать фактические трудозатраты по задачам и упростит работу скрам-мастера.

Все встречи проектной команды: ежедневные митинги, обзоры спринтов и ретроспективы должны проводиться в соответствии с методологией Scrum. Подробно с процессом проведения подобных встреч, целями, ключевыми вопросами и так далее, можно ознакомиться в книге К. Швайбера и Д. Сазерленда «Scrum гайд. Исчерпывающее руководство по Scrum: правила игры».

5. УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОДУКТА

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

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

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

...