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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. ОЦЕНКА СОСТОЯНИЯ ПРОЕКТА

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

Метрики были разделены на 4 группы в зависимости от направления:

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

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

• качество;

• ценности.

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

Ниже приведен список метрик, которые предлагаются для оценки производительности:

· Velocity - количество задач, которые были реализованы за один спринт.

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

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

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

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

Классически Velocity рассчитывается в конце спринта. Каждая реализованная задача имеет относительную оценку сложности, которая измеряется в сторипоинтах. Сложность определяется относительно эталонной задачи, которая является понятной и простой с точки зрения реализации для команды. Методы оценки сторипоинтов выделяют разные: числа Фибоначчи, метод «размера одежды», метод логарифмической линейки.

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

Таблица 10. Дискретная логарифмическая шкала оценки задач

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

Плановые трудозатраты рассчитываются исходя из следующих факторов:

• длительность спринта (количество рабочих дней, выпадающих на спринт);

• количество людей в команде, задействованных на спринт;

• загрузка по проекту (количество часов в день).

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

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

Рисунок 14. Пример диаграммы сгорания спринта

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

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

· Technical Debt Points - это показатель, отражающий процент трудозатрат в спринте, запланированных на устранение низкоприоритетных ошибок, оптимизацию существующего кода.

· Post Sprint Defect Arrival - количество ошибок, которые возникают после окончания спринта и относящиеся к задачам предыдущих спринтов.

· Post Release Defect Arrival - количество ошибок, которые возникают после релиза.

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

Показатель Post Sprint Defect Arrival рассчитывается по окончании каждого спринта, а Post Release Defect Arrival рассчитывается по окончании каждой итерации. Чем меньше значение этих двух показателей, тем лучше налажен на проекте процесс тестирования и инспекций.

Подходы для оценки ценности

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

· Customer Satisfaction Survey - опрос, используемый, чтобы оценить, насколько заказчик удовлетворен программным продуктом и насколько он соответствует потребностям бизнеса.

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

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

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

Как уже говорилось ранее, при использовании гибких методологий успех проекта тесно связан с хорошими взаимоотношениями между участниками проекта. Скрам-мастеру важно понимать, как колеблется настроение сотрудников в процессе работы, так как это может оказать влияние на результат их работы. Для мониторинга состояния сотрудников можно применять Niko-niko календарь (см. Рисунок 15), что в переводе означает «календарь улыбок».

Рисунок 15. Пример использования niko-niko календаря

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

Размещено на Allbest.ru