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

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

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

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

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

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

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

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

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

• качество;

• ценности.

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

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

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

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

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

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

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

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

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

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

,

где n - количество реализованных историй пользователя за итерацию.

Имея данные по Velocity за предыдущие спринты, возможно прогнозирование количества решаемых задач последующего спринта.

Как оценивать Velocity: чем больше значение показателя, тем больше команда сделала за спринт, но так как на значение данного показателя влияет большое количество факторов, опираться только на него не стоит.

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

Показатели Storу Cycle Time, Lead Cycle Time и Wasted Time могут рассчитываться как по окончанию спринта, так и в его середине. Для оценки используют среднее значение этих показателей за период (спринт). Чем меньше значение каждого из этих показателей, тем быстрее и слаженней работает команда.

Показатель Work in Progress (WIP) играет ключевую роль при использовании методологии Kanban. Согласно набору данных предложений предлагается применять практики Kanban, поэтому настоятельно рекомендуется использовать данный показатель. Расчет показателя можно производить как по окончании спринта, так и на ежедневной основе в качестве среза текущей деятельности.

Производить расчет необходимо по каждому этапу работы над историей пользователя, т.е. если этапы работы разделены на: анализ, проектирование, разработку и тестирование, то должны быть зафиксированы четыре значения WIP. Согласно подходу Kanban, следует стремиться, чтобы WIP не превышал 3 задачи на одном этапе одновременно.

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

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

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

· Sprint Burndown Chart - Chart - это диаграмма, позволяющая ответить на вопрос о степени готовности задач, и понять укладывается ли команда в рамки спринта.

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

Нужно стремиться, чтобы значение показателя стремилось к 1, то есть к соответствию плановых трудозатрат фактическим. Допустимым считается колебание в 0,2. Значение показателя нужно трактовать следующим образом:

· Значение показателя равно 1 - оценка была проведена верно, абсолютное совпадения плана и факта.

· Значение показателя меньше 1 - задача было недооценена.

· Значение показателя больше 1 - задача было переоценена.

По окончании проекта может быть построена общая диаграмма аккуратность оценки задач (см. Рисунок 13).

Рисунок 13. Диаграмма аккуратности оценки задач за период

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