Вы находитесь на странице: 1из 33

СОДЕРЖАНИЕ

ВВЕДЕНИЕ…………………………………………………………………………..3
ГЛАВА I. СПЕЦИФИКА ВВЕДЕНИЯ И ИСПОЛЬЗОВАНИЯ AGILE…………6
1.1 Статистика итогов введения проектов…………………………………………6
1.2 Выгода от внедрения Agile……………………………………………………...7
1.3 Методы внедрения……………………………………………………………….7
ГЛАВА II. ОБЗОР ОПЫТА КОМПАНИЙ, КОТОРЫЕ ВВЕЛИ AGILE………...9
2.1 Кейс Zara…………………………………………………………………………9
2.2 Кейс Biletix……………………………………………………………………...10
2.3 Кейс Unicredit…………………………………………………………………...12
ГЛАВА III. ИЗУЧЕНИЕ ПОЗИЦИЙ СПЕЦИАЛИСТОВ AGILE И АНАЛИЗ
ИТОГОВ ОТВЕТОВ………………………………………………………………..13
3.1 Методика………………………………………………………………………..13
3.2 Итоги ответов…………………………………………………………………...14
3.3 Заключение по итогам ответов………………………………………………...16
ГЛАВА IV. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ИЗМЕНЕНИЙ В ПРОЕКТАХ
ПОСЛЕ ВНЕДРЕНИЯ AGILE МЕТОДОЛОГИИ В КРУПНОЙ RETAIL
КОМПАНИИ……………………………………………………………………….17
4.1 Обзор компании и анализ ее деятельности…………………………………...17
4.2 Структура компании…………………………………………………………...17
4.3 Метрики…………………………………………………………………………17
4.4 Сравнительный анализ изменений в проектах после внедрения Agile……..18
4.4.1 Проект 1……………………………………………………………………….19
4.4.2 Проект 2……………………………………………………………………….23
4.5 Выводы по анализу изменений в проектах после внедрения Agile
методологии в крупной Retail компании………………………………………….28
ЗАКЛЮЧЕНИЕ……………………………………………………………………..31
СПИСОК ЛИТЕРАТУРЫ………………………………………………………….32

2
ВВЕДЕНИЕ

Этот тезис фокусируется на реалистичной реализации гибкого подхода к


бизнесу в сфере розничной торговли.
В условиях неопределенности рынка, а также в условиях классической
конкуренции предприятия (в частности, розничный сектор) сталкиваются с
необходимостью резко оптимизировать издержки и быстро адаптироваться к
изменениям [2].
По сравнению с традиционным подходом, Agile помогает вам быстро
изменить направление и воплотить в жизнь новые, более ценные и применимые
бизнес-разработки в данный момент, поскольку Agile работает над
технологиями, которые больше беспокоят бизнес. Именно эта стратегия
поможет вам сохранить первоначальный бюджет проекта или даже снизить
затраты на проект.
Согласно отчету о хаосе [5], подготовленному партией Стэндиша,
предприятия, которые использовали модель водопада, были на 11%
успешными, на 60% спорными, на 29% неэффективными. Проекты,
использующие гибкие методы, имеют следующие прогностические
характеристики: 39% успешных проектов, 52% спорных проектов и 9%
неудачных проектов. Использование гибких методов помогает вам утроить
успех выполнения по сравнению со стандартным подходом (в процентах).
Еще несколько лет назад термин Agile был тесно связан с инициативами,
связанными только с разработкой программного обеспечения, поскольку
гибкие методологии не подходили для промышленности. Однако, когда
крупные компании начинают использовать Agile, наблюдается также тенденция
к быстрому распространению концепций гибкого управления на другие
отрасли[4].
Целью исследования является внедрение гибкой методологии
Тема исследования-Особенности реализации гибкого подхода к бизнесу в
сфере розничной торговли.
3
Цели и задачи:
Целью данной работы является: обзор функциональной реализации
гибкой методологии для предприятий розничной торговли, выявление проблем,
применение масштабируемого подхода к розничным компаниям и методов их
решения.
Для достижения поставленных приоритетов необходимо решить целый
ряд задач:
1. Определите характеристики гибкой реализации и применения: задачи,
методологии, методы.
2. дайте описание розничных ситуаций организаций, принявших Agile, и
оцените результаты внедрения.
3. провести опрос экспертов Agile для выявления причин принятия,
проблем, возникающих при внедрении, преимуществ, полученных гибким
подходом, и эффективности гибкой методологии для розничного рынка.
4. проведение качественного исследования улучшений в программах
после внедрения гибкого подхода в крупном розничном бизнесе.
Работа разделена на четыре главы. Методология анализа-сравнительный
анализ.
В первой главе рассматриваются причины принятия, преимущества
внедрения, проблемы внедрения, методологии гибкого внедрения и
инструменты гибкого применения.
Вторая глава посвящена анализу розничных ситуаций в организациях,
принявших Agile. Оцениваются и иллюстрируются ключевые выводы,
достигнутые компаниями, а также итоговая таблица результатов внедрения
Agile для рассматриваемых компаний.
В третьей главе обсуждаются мнения гибких специалистов с помощью
опроса и анализируются результаты ответов. Сравнительное исследование
целей внедрения Agile, преимуществ внедрения Agile, проблем, выявленных
при внедрении Agile, приведено в первой главе (данные взяты из ежегодного
отчета о состоянии Agile первой версии с результатами опроса ответов.
4
В четвертой главе представлен сравнительный обзор усовершенствований
программ после внедрения гибкого подхода в крупном розничном бизнесе.
Приоритеты и преимущества внедрения Agile в крупном розничном бизнесе
были сопоставлены с выводами доклада "Анализ практического применения
Agile в розничной торговле".

5
ГЛАВА I. СПЕЦИФИКА ВВЕДЕНИЯ И ИСПОЛЬЗОВАНИЯ AGILE

1.1 Статистика итогов введения проектов

На основании предыдущего раздела нетрудно сделать вывод, что


существуют достаточные основания для реалистичного внедрения Agile в
розничном секторе. В качестве доказательства этого исследования можно
привести данные об эффективности выполнения проекта, основанные на отчете
о хаосе за 2015 год[5], подготовленном постоянной стороной.
Отчет о хаосе периодически выпускается с 1994 года и представляет
собой моментальный снимок состояния индустрии разработки программного
обеспечения. Данные о развертывании приведены в таблице 1.1.
Таблица 1.1 Отчеты о влиянии проблемы [1]

Размер проекта Модель Удачное окончание Неоднозначные Неудачное окончание


проекта проекты проекта
Все проекты Agile 39% 52% 9%
Waterfall 11% 60% 29%
Крупные Agile 18% 59% 23%
Waterfall 3% 55% 42%
проекты
Проекты Agile 27% 62% 11%
Waterfall 7% 68% 25%
средних
размеров
Маленькие Agile 58% 38% 4%
Waterfall 44% 45% 11%
проекты

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


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

1.2 Выгода от внедрения Agile

6
Преимущества внедрения Agile стратегий тесно связаны с причинами их
внедрения в бизнес, о чем говорится во введении. Однако в этом разделе
основное внимание будет уделено следующему аспекту: экономии средств.
В условиях неопределенности рынка, а также в условиях классической
конкуренции предприятия (в частности, розничного сектора) столкнулись с
необходимостью кардинальной оптимизации затрат. Однако традиционные
подходы к управлению проектами значительно уступают гибким методам,
поскольку априорные гибкие методы способствуют экономии затрат. Это
происходит потому, что гибкие подходы, по-видимому, специально влияют на
самый большой недостаток традиционного подхода: большая часть времени
обычно тратится (особенно в смысле затрат на написание правильной
документации), потому что значительный объем переделок и переделок
возникает непреднамеренно при реализации этого подхода. В некоторых
случаях менее 25% спецификаций будут применяться в их первоначальном
виде[2]. В то время как в Agile вы можете рассмотреть возможность отсрочки
распределения бюджета до максимально возможной ясности. [2] (2) [2]
Другими словами, при традиционном методе много времени тратится на
проведение семинаров для оценки дополнительных затрат на улучшение,
перепланировку и переработку части работы. В Agile выбор очень прост: при
принятии решения в данный момент необходимо внедрить новое, более ценное
и подходящее для компании изобретение, поскольку Agile делает акцент на
разработках, которые являются более приоритетными для бизнеса. Именно эта
стратегия помогает вам, по крайней мере, сохранить первоначальный бюджет
проекта или даже сократить расходы на проект.

1.3 Методы внедрения

Методология применения Agile основана на четырех концепциях,


опубликованных в Agile Manifesto[1] в феврале 2001 года. Давайте рассмотрим
эти принципы более подробно.
7
1. Люди и отношения важнее систем и ресурсов.
2. рабочий продукт важнее подробного текста.
3. Сотрудничество с клиентом является более важным, чем консенсуса по
условиям сделки.
4. подготовка к переходу имеет более важное значение, чем выполнение
первоначального графика.
Характерным различием между гибким и традиционным подходом
является восприятие того, что конечная цель может измениться в ходе
выполнения проекта. Также важно и целесообразно учитывать эти улучшения,
чтобы результаты проекта полностью соответствовали бизнес-цели и
выполняли поставленные перед ним задачи. Гибкие методологии с их
непрерывной итерацией требуют постоянной подготовки.
Философия исполнения основана на вышеприведенных постулатах, но
она также включает в себя двенадцать концепций гибкого роста, которые
можно найти более подробно в том же гибком Манифесте[1]. Версия первая в
своем 11-м ежегодном обзоре состояния Agile предложила советы по
эффективному масштабированию Agile.

8
ГЛАВА II. ОБЗОР ОПЫТА КОМПАНИЙ, КОТОРЫЕ ВВЕЛИ
AGILE

2.1 Кейс Zara

К середине 2000-х годов Зара присоединилась к сцене, называя себя


"быстрой модой", продвигая высокую моду по складским ценам. В год они
производят от 10 000 до 15 000 новых моделей и продают их в тысячах
магазинов по всему миру. Менеджер Zara, Амансио Ортега, в настоящее время
является самым богатым человеком в Европе с состоянием, оцениваемым более
чем в 70 миллиардов долларов.
В своем исследовании Галин Желязков [8] определил основные аспекты
деятельности Zara в гибкой цепочке поставок (ASC) и выявил дыры в бизнесе
Zara, которые необходимо устранить, чтобы сделать бизнес более успешным. За
последние десятилетия Zaira вывела Agile Supply Chain (ASC) на рынок
быстрой моды и стала третьим по величине ритейлером в мире. Это привело к
прекращению партнерства между потребителями и дизайнерами и перспективе
отправки продукции в магазин в течение недели.
Кайфэн [9] в своем анализе предполагает, что жизненный цикл товаров и
инноваций, вероятно, будет продолжать сокращаться, хотя спрос чрезвычайно
трудно прогнозировать. Необходимость заранее договариваться о сырье по-
прежнему является самым опасным аспектом гибкой цепочки поставок.
Поведение потребителей улучшилось, и теперь потребители чаще видят новый
продукт[10].
Это просто продукт действий новых клиентов, одежда больше не
используется для защиты тела от холода, она отображает стиль человека[9].
Оба эти аспекта играют решающую роль в новом альянсе между розничными
торговцами, поставщиками и клиентами.
Управление цепочками поставок (SCM) - это драйвер успеха в быстрой
моде. Это относится к производителям, потребителям и поставщикам. Это
9
касается процесса от источников сырья до потребления товара. Выход из
цепочки поставок - это не только материальный товар, но и смесь времени,
места, типа и особенностей предложения продукта/услуги[9].
В секторе моды, где бизнес конкурирует по времени (time to market),
растет потребность в новых навыках. Гибкость - это способность быстро
реагировать на изменения спроса. Кайфэн [9] описывает гибкую цепочку
поставок (ASC) как способность компании постоянно находить и захватывать
рыночные возможности быстрее, чем ее конкуренты. Барнс и Гринвуд [11]
усилили эту концепцию, добавив: ASC-это "быстрый ответ", представляющий
более короткие и универсальные цепочки поставок, зависящие от спроса. ASC
обрабатывает такую информацию, как статистика потребителей и обмен
информацией между фирмами в цепочке поставок. В гибких цепочках поставок
наглядность знаний помогает цепочке поставок быстрее адаптироваться к
изменениям потребительского спроса.
Гибкое производство является частью процесса ASC. Цай-фэн [9]
указывает на четыре ключевые цели гибкого производства: увеличить число
потребителей быстрее, чем конкуренты, осуществить массовую кастомизацию
за счет массовой обработки, справиться с переходом и волатильностью за счет
частой адаптации систем и увеличить влияние на людей в отраслях с помощью
информационных технологий.

2.2 Кейс Biletix

Biletix - российский онлайн-туроператор и поставщик билетных услуг.


Компания была основана в 2008 году. В 2016 году объем продаж компании
составил 10,9 млрд рублей, что поставило ее на 11-е место в списке Forbes
самых дорогих компаний электронной коммерции[22].
Biletix специализируется на бронировании и продаже авиа-и
железнодорожных билетов, отелей, пакетных поездок, проката автомобилей.
Бизнес обрабатывает более 5000 транзакций в день. Для круглосуточного
10
обслуживания клиентов организация имеет три колл-центра, расположенных в
разных уголках России. Каждый день организация развивает свои ИТ-
технологии онлайн-путешествий. В 2010 году компания Biletix представила
функции онлайн-продаж отелей. После 2011 года фирма также предлагала
планы страхования путешествий в Интернете. Biletix стала первой
организацией в России, которая начала онлайн-продажу чартерных билетов
(2012). 2013 год станет плодотворным для организации новых проектов: будут
внедрены приложения для смартфонов и появится новое направление
деятельности-онлайн-прокат автомобилей[23].
Однако в 2016 году руководство организации заявляет, что Biletix теряет
обороты в росте, и решает внедрить в компании масштабируемый подход к
управлению проектами[24]. Причины гибкой реализации заключаются в
следующем:
- низкий уровень контактов между отделами;
- согласование действий с руководством компании;
- низкая мотивация персонала в офисе;
- низкое понимание работников офиса;
- неустойчивая динамика в реализации стратегически важных проектов;
- опасность аннулирования конкурса
Билетиксу потребовался месяц, чтобы обучить своих работников новому
стилю работы и скорректировать руководящие принципы управления рабочим
процессом. Головной офис компании состоит из пятидесяти сотрудников. Все
рабочие были разделены на шесть команд по пять-семь человек в каждой.
Рабочая сила произвольно делится на команды на пятьдесят процентов.
Каждый сотрудник может перейти в другую команду по своему выбору.
Руководители подразделений были названы руководителями команд[24].
Для вдохновения рабочих был учрежден призовой фонд в семьсот
пятьдесят тысяч рублей. Каждая команда получила только две задачи, которые
должны были быть выполнены в течение пяти месяцев.

11
2.3 Кейс Unicredit

Unicredit - один из крупнейших банков Европы. UniCredit-относительно


молодая компания, основанная в 1998 году, когда были объединены девять
итальянских банков. С тех пор к нему добавились банки из Польши, Болгарии,
Словакии, Чехии, Германии и Турции. [32] [32]
UniCredit стремится объединить эти разрозненные банки в единую
бизнес-модель. Ее руководители поставили перед собой задачу обеспечить,
чтобы любой клиент был представлен наиболее подходящим консультантом."
Это усиливает потребность в квалифицированных лидерах, поэтому UniCredit
создал Центр управления Uni в Турине, чтобы создать критическое учебное
сообщество. Центр построен для того, чтобы сделать обучение проще.
Ежегодно мастерские центра посещают тысячи сотрудников [32].
Для пилотного внедрения Scrum были выбраны приложение для
смартфона и веб-сайт банка. Именно с помощью этих инструментов клиент
чаще всего общается с банком и может легко оценить реакцию клиента на
изменения. Для внедрения Scrum банк выбрал только часть веб-и сервисных
функций. Изменения коснулись: клиентской части приложений, передней и
задней части интернета и смартфона. Банковская система (ESB, back end
banking system) осталась неизменной.

12
ГЛАВА III. ИЗУЧЕНИЕ ПОЗИЦИЙ СПЕЦИАЛИСТОВ AGILE И
АНАЛИЗ ИТОГОВ ОТВЕТОВ

3.1 Методика

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


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

13
3.2 Итоги ответов

Данные подлежат: анализу множественных ответов, частотным таблицам,


таблицам непредвиденных обстоятельств. Все измерения были сделаны в SPSS.
PI (Implementation Purpose)-с какой целью вы приняли (или внедряете)
гибкое управление проектами?
BR (полученные выгоды) - каковы преимущества гибкого управления
проектами?
PU (Using Challenges) - с какими проблемами вы столкнулись, используя
универсальное управление проектами?
SE (System Efficiency) - масштабируемая система управления проектами в
организации определяется как эффективная.
Представленный набор элементарных переменных был разделен на
наборы нескольких дихотомий. После этого были запланированы таблицы
частот для векторных наборов. Частотные таблицы представляют частоту
(количество наблюдений), процент ответа, процент наблюдений, количество
случаев без пропущенных значений и количество пропущенных случаев.
Кросс-таблицы с различными ответами составляют таблицы
непредвиденных обстоятельств для заданного набора переменных,
элементарных переменных или их комбинации.
Таблица 2.1 Отчет наблюдений [2]

Наблюдения
Валидные Пропущенные Итого
N % N % N %
$PIa 40 95,2% 2 4,8% 42 100,0%
$BKa 37 88,1% 5 11,9% 42 100,0%
$PUa 41 97,6% 1 2,4% 42 100,0%
$SEa 41 97,6% 1 2,4% 42 100,0%
a. Группа дихотомий записана в таблицу в момент значения 1.

Таблица 2.2 Частота ответов на вопрос PI [2]

14
Ответы %
N % наблюдений
PIa 1 Увеличить удовлетворенность клиента 21 14,8% 52,5%
1 Увеличить скорость разработки/поставки товара 32 22,5% 80,0%
1 Иметь возможность функционировать с изменяющимися 24 16,9% 60,0%
приоритетами
1 Уменьшить риски проектов 9 6,3% 22,5%
1 Увеличить прозрачность работы над проектами 21 14,8% 52,5%
1 Увеличить заинтересованность всей команды 15 10,6% 37,5%
1Уменьшить расходы 8 5,6% 20,0%
1 Улучшить качество 12 8,5% 30,0%
В сумме 142 100,0% 355,0%
a. В таблице приведена группа дихотомий в момент значения 1.

Таблица 2.3 Частота ответов на вопрос BK [3]

Ответы %
N % наблюдений
BKa 2 Возможность манипулировать изменяющимися 26 21,1% 70,3%
приоритетами
2 Увеличение удовлетворенности клиентов 18 14,6% 48,6%
2 Увеличение скорости создания товара 22 17,9% 59,5%
2 Улучшение качества итогов проектов 14 11,4% 37,8%
2 Уменьшение рисков проектов 8 6,5% 21,6%
2 Прозрачность в создании проектов 20 16,3% 54,1%
2 Уменьшение цены на разработку 6 4,9% 16,2%
2 Увеличение точности планирования 9 7,3% 24,3%
В сумме 123 100,0% 332,4%
a. В таблице приведена группа дихотомий в момент значения 1.

Таблица 2.4 Частота ответов на вопрос PU [3]

Ответы %
N % наблюдений
PUa 3 Не сильно жесткое соблюдение правил agile манифеста 14 14,3% 34,1%
3 Слишком большое количество встреч, дискуссий, планирований 10 10,2% 24,4%
3 Неопределенность окончательного итога 14 14,3% 34,1%
3 Сопротивление переменам со стороны участников проектных групп 13 13,3% 31,7%
3 Отсутствие документации, трудности во время появлении новых 12 12,2% 29,3%
участников группы проекта
3 Отсутствие инструментов определения результативности 13 13,3% 31,7%
3 Малый опыт в использовании подхода Agile 22 22,4% 53,7%
В сумме 98 100,0% 239,0%
a. В таблице приведена группа дихотомий в момент значения 1.

Они измеряют процент клеток на основе измерений или реакций,


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

3.3 Заключение по итогам ответов

Исходя из результатов ответов, было отмечено, что большинство


респондентов достигли своих целей благодаря внедрению Agile. Приоритеты
применения Agile совпадают с приоритетами внедрения в 73 процентах
случаев. Самый низкий уровень перекрытия-33,3 процента-был обусловлен
экономией средств. Самое большое совпадение-100% - ное достижение целей
ускорения разработки/поставки продукта и повышения подотчетности
выполнения проекта. Это означает, что Agile в первую очередь ориентирован
на увеличение темпов разработки/доставки продукта и повышение ясности
выполнения проекта. На основе анализа полученных ответов была установлена
взаимосвязь между приоритетами и эффективностью гибкого подхода в
организации. В 86 процентах случаев Agile имеет самую высокую степень
производительности с целью повышения открытости управления проектами.
Опрос подтвердил наиболее распространенные причины внедрения Agile,
как показано в Главе 1. Аналогично, сравнение результатов отчета Version One
State of Agile с результатами опроса выявило пробелы в приоритетах,
преимуществах и препятствиях для розничного рынка.

ГЛАВА IV. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ИЗМЕНЕНИЙ В ПРОЕКТАХ


ПОСЛЕ ВНЕДРЕНИЯ AGILE МЕТОДОЛОГИИ В КРУПНОЙ

co
ПРОДУКТОВОЙ RETAIL КОМПАНИИ WALMART

4.1 Обзор компании Walmart и анализ ее деятельности

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


является оптовая и розничная торговля продовольственными товарами.

16
Компания была основана в 1962 году. Сегодня это одна из крупнейших
сетей супермаркетов в стране. Магазины компании базируются в следующих
странах: Канада, Южная Америка, Великобритания, Южная Африка, Китай и
Япония. По состоянию на 2012 год общее количество магазинов составляет
более 11 700, в том числе 410 в Канаде, 1607 на юге США, 631 в
Великобритании, 373 в Южной Африке, 439 в Китае и 341 в Японии.
Право собственности-ограниченная юридическая ответственность
общества.
По данным Forbes Global 2000, в 2017 году компания заняла 17-е место в
списке крупнейших общественных организаций мира с годовым оборотом в
485,9 миллиарда долларов.

4.2 Структура компании

Структура компании представлена на рисунке 13. Схема иллюстрирует


иерархическое взаимодействие и взаимодействие между членами команды.

4.3 Метрики

Бизнес использует инструмент фиксации и мониторинга рабочих мест-


JIRA[43]. Роли видны как в списке, так и на доске канбан.
Период цикла-время, в течение которого осуществлялась миссия с
момента ее начала и до завершения фактического процесса осуществления.

17
Рисунок 1. Структура работодателя
НЗП-количество вещей, работающих одновременно. Она разбита на
различные этапы работы над миссией.
Опережающий период-время от появления миссии до ее фактического
выполнения. Требуется время цикла и время очереди выполнения.
Потерянное время-время, которое работа проводит в отдельных очередях,
а не непосредственно на работе.
Эффективность - это количество времени, потраченное непосредственно
на работу, а не на ожидание в отдельных очередях.
Пропускная способность-количество задач, которые команда может
выполнить в единицу времени (день, неделя, месяц).

4.4 Сравнительный анализ изменений в проектах после внедрения


Agile

18
4.4.1 Проект 1

• Вид заданий – «Устранение ошибки»


Таблица 4.1.1 Показатели заданий на устранение ошибок в проекте 1 [5]

Метрики Стандартная методика Agile


Дата начала (дата) 21.06.2017 05.12.2017
Дата завершения (дата) 21.11.2017 14.03.2018
Итоговое время работы по методике (в днях) 153 99
Итоговое количество ошибок, возникших за все это время 144 108
Среднее количество ошибок в день 1,455 0,705
Коэффициент роста ошибок (отношение количества ошибок 2,58 -0,7
последнего месяца к первому)

Общее количество ошибок после гибкой реализации в три раза больше,


чем до гибкой реализации. Это объясняется тем, что до внедрения Agile
комплексная разработка системы не проводилась, а вместо этого был проверен
практический прогресс. Часто люди начинали использовать фреймворк более
активно, чем раньше, они начинали называть больше функций. В результате
было обнаружено несколько дефектов, которые не были обнаружены в
процессе тестирования. Если вы посмотрите на дефектную скорость разработки
после внедрения Agile, то она была намного меньше, чем до внедрения Agile.
Это означает, что совокупное количество дефектов начинает уменьшаться.
На рисунке 1 показаны результаты созданных запросов. Дефекты, парень.
Проект 1 указывает количество дефектов, которые были созданы с помощью
проекта/фильтра в данный момент времени, и количество дефектов, которые
были исправлены. Это указывает на то, что команда выполняет свою работу.
Поскольку на карте нет красных столбиков, это означает, что каждая
неисправность была исправлена (исправлена) в течение месяца. Можно также
показать, что среднее число дефектов в месяц продолжает снижаться после
декабря.
• Тип заданий – «Создание новых функций»
Общее количество задач, которые должны быть выполнены после
внедрения Agile, выше, чем до внедрения Agile. Это связано с тем, что в момент

19
принятия решения о переходе на Agile был создан "пузырь" задач и что,
выполнив Agile, все задачи, которые ранее только что были решены, были
занесены в бэклог.

Задачи
35

30

25

20

15 Задачи
10

0
7 7 7 7 7 7 7 8 8 8
2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01
нь ль ст ь ь ь ь ь ь т
ю ю вгу ябр ябр ябр абр вар рал ар
И И нт т к М
А
Ок Но Де Ян Фе
в
Се

Рисунок 1. Гистограмма «Сделанные запросы. Ошибки. Проект 1»


Таблица 4.1.2 Показатели заданий на создание новых функций в проекте
1 [7]

Метрики Стандартная методика Agile


Дата начала (дата) 15.06.2017 01.12.2017
Дата окончания (дата) 30.11.2017 19.03.2018
Итоговое время работы по методике (в днях) 168 108
Итоговое количество заданий, возникших за все это 280 252
время
Среднее количество заданий в день 1,67 2,33
Коэффициент роста заданий (отношение количества 1,22 1,12
заданий последнего месяца к первому)

На рисунке 2 показаны созданные запросы. Задачи по созданию новых


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

20
снижаться после января.

Задачи
80
70
60
50
40
Задачи
30
20
10
0
7 7 7 7 7 7 7 8 8 8
2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01 2 01
нь ль ст ь ь ь ь ь ь т
ю ю вгу ябр ябр ябр абр вар рал ар
И И нт т к М
А
Ок Но Де Ян Фе
в
Се

Рисунок 2. Гистограмма «Сделанные запросы. Задания на создание новых


функций. Проект 1»
• Вид заданий – «Все задания»
Таблица 4.1.3 Показатели заданий всех видов в проекте 1 [7]

Метрики Традиционная методика Agile


Дата начала (дата) 15.06.2017 01.12.2017
Дата окончания (дата) 30.11.2017 19.03.2018
Итоговое время работы по методике (в днях) 168 108
Итоговое количество заданий, возникших за все это время 428 408
Среднее количество заданий в день 2,55 3,78
Коэффициент роста заданий (отношение количества 1,93 -0,3
заданий последнего месяца к первому)

С момента внедрения Agile общее количество заданий стало в два раза


больше, чем до внедрения Agile. Это связано с тем, что на момент принятия
решения о переходе на Agile был создан "пузырь" задач по созданию нового
функционала и при внедрении Agile все задачи, которые ранее уже были
решены, были занесены в бэклог.
На рисунке 3 показаны результаты созданных запросов. Любое из
заданий. Проект 1 указывает количество задач, сгенерированных за заданное
время для проекта / фильтра, и количество задач, которые были решены. Это
21
указывает на то, что команда выполняет свою работу. Поскольку красных
столбиков на карте мало, это означает, что, вообще говоря, команда
справляется, но приоритет нужно отдавать отложенным задачам.
160

140

120

100

80

60 Задачи
Столбец1
40

20

0 17 0 17 0 17 01
7
01
7
01
7
01
7
01
8
01
8
01
8
ь2 ь2 ст2 ь 2 ь 2 ь 2 ь 2 ь 2 ь 2 т 2
н л гу бр бр бр бр ар ал ар
Ию Ию Ав нт
я тя я ка
Ян
в вр М
Ок Но Де Фе
Се

Рисунок 3. Гистограмма «Сделанные запросы. Все задания. Проект 1»


Круговая диаграмма (рисунок 4) и таблица 3 показывают все виды
проблем и связанные с ними затраты труда. Большая часть времени, 63% этой
формы работы посвящается созданию новых функций. Однако ценность
мероприятий по исправлению дефектов все еще очень велика и составляет 30%.
Таблица 4.1.4 Виды сложностей и трудозатраты по ним [7]

Вид задания Количество %


Создание 543 65%
программного
обеспечения
Устранение ошибки 201 24%
Другое 50 6%
Управление 42 5%

22
Разработка ПО
Исправление дефекта
Другое
Администрирование

Рисунок 4. Виды сложностей и трудозатраты по ним


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

4.4.2 Проект 2

• Вид заданий – «Устранение ошибки»


Таблица 4.2.1 Показатели заданий на устранение ошибок в проекте 2 [9]

Метрики Стандартная методика Agile


Дата начала (дата) 10.01.2017 03.12.2017
Дата окончания (дата) 29.11.2017 15.03.2018
Итоговое время работы по методике (в днях) 323 102
Итоговое количество ошибок, возникших за всеэто время 684 112
Среднее количество ошибок в день 2,12 1,1
Коэффициент роста ошибок (отношение количества ошибок 0,92 -0,71
последнего месяца к первому)

Общее количество ошибок после гибкой реализации меньше, чем до


гибкой реализации. Если посмотреть на темпы роста дефекта, то после
внедрения Agile он меньше, чем до внедрения Agile. Это означает, что
совокупное количество дефектов начинает уменьшаться.
На рисунке 5 показаны результаты созданных запросов. Дефекты, парень.
Проект 2 указывает количество неисправностей, сгенерированных для
23
продолжительности проекта / фильтра, и количество исправленных
неисправностей. Это указывает на то, что команда выполняет свою работу.
Поскольку на карте нет красных столбиков, это означает, что любая
неисправность была исправлена (исправлена) в течение месяца. Вы также
увидите, что среднее количество дефектов в месяц продолжает снижаться после
декабря.

Задачи
90
80
70
60
50
40 Задачи
30
20
10
0
7 7 7 7 7 7 7 7 7 7 7 7 8 8 8
2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 20 1 2 0 1 2 0 1
рь ль рт ль ай нь т
ль гус брь брь брь брь арь аль ар т
нва вра Ма пре М Ию Ию
Ав нтя ктя Ноя ека Янв евр М
Я Фе А
Се О Д Ф

Рисунок 5. Гистограмма «Сделанные запросы. Ошибки. Проект 2»


• Вид заданий – «Создание новых функций»
Общее количество задач после внедрения Agile меньше, чем до внедрения
Agile. Это объясняется тем, что система начинает полностью выполнять
требования пользователей и что пользователи не должны начинать
деятельность по реализации дополнительных функций.
Таблица 4.2.2 Показатели заданий на создание новых функций в проекте
2 [9]

Метрики Стандартная методика Agile


Дата начала (дата) 10.01.2017 03.12.2017
Дата окончания (дата) 29.11.2017 15.03.2018
Итоговое время работы по методике (в днях) 323 102
Итоговое количество заданий, возникших за все это 992 132
время
Среднее количество заданий в день 3,07 1,29
Коэффициент роста заданий (отношение количества 0,97 -0,71
24
заданий последнего месяца к первому)

120

100

80

60

Задачи
40

20

0
7 7 7 7 7 7 7 7 7 7 7 7 8 8 8
2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 20 1 2 0 1 20 1
рь ль т ь ай юнь юль ст ь ь ь ь ь ь т
ва ра ар рел М вгу я бр я бр ябр а бр вар р ал ар
н в М И И т т к н в М
Я Фе Ап А н Ок Но Де Я Фе
Се

Рисунок 6. Гистограмма «Сделанные запросы. Задания на создание новых


функций. Проект 2»
На рисунке 6 показаны результаты созданных запросов. Задачи по
созданию новых функций. Проект № 2 " указывает количество задач,
сгенерированных за заданное время для проекта / фильтра, и количество задач,
которые были решены. Это поможет вам увидеть, как команда выполняет свою
работу. Поскольку красных столбиков на карте мало, это означает, что, вообще
говоря, команда справляется, но приоритет нужно отдавать отложенным
задачам.
• Вид заданий – «Все задания»
Таблица 4.2.3 Показатели заданий всех видов в проекте 2 [9]

Метрики Стандартная методика Agile


Дата начала (дата) 10.01.2017 03.12.2017
Дата окончания (дата) 29.11.2017 15.03.2018
Итоговое время работы по методике (в днях) 323 102
Итоговое количество заданий, возникших за все это 1696 284
время
Среднее количество заданий в день 5,25 2,78
Коэффициент роста заданий (отношение количества 1,35 0,96
заданий последнего месяца к первому)

25
Общее количество задач после внедрения Agile меньше, чем до внедрения
Agile. Это объясняется тем, что фреймворк начинает полностью выполнять
требования пользователя, а пользователи не предпринимают действий по
созданию дополнительных функций, а также падением количества дефектов.
На рисунке 7 показаны созданные запросы. Любое из заданий. Проект 2
отображает количество задач, сгенерированных в течение заданной
продолжительности проекта / фильтра, и количество задач, которые были
решены. Это указывает на то, что команда выполняет свою работу. Поскольку
красных столбиков на карте мало, это означает, что, вообще говоря, команда
справляется, но приоритет нужно отдавать отложенным задачам.
Круговая карта (рисунок 9) и таблица 4.2.4 показывают всевозможные
проблемы и связанные с ними затраты труда. Большую часть времени 61% этой
формы работы посвящено созданию современных функций. Однако ценность
мероприятий по исправлению дефектов по-прежнему очень велика и составляет
34%.
250

200

150

100
Задачи
Столбец1
50

0
7 7 7 7 7 7 7 7 7 7 7 7 8 8 8
2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 0 1 20 1 2 0 1 20 1
ь ь т ь й ь ь т ь ь ь ь ь ь рт
вар рал ар рел Ма юн юл вгус ябр ябр ябр абр вар рал а
М И И А нт Окт Но Дек Ян Фев М
Ян Фев Ап е
С

Рисунок 7. Гистограмма «Сделанные запросы. Все задания. Проект 2»

26
Разработка ПО
Исправление дефекта
Администрирование
Другое
Консультация
Пометка

Рисунок 9. Виды сложностей и трудозатраты по ним


Таблица 4.2.4 Виды сложностей и трудозатраты по ним [9]

Вид задания Количество %


Создание 1089 55%
программного
обеспечения
Устранение ошибки 752 38%
Управление 79 4%
Другое 40 2%
Консультация 14 0.7%
Пометка 2 0.1%

Внедрение гибкого подхода оказало положительное влияние на проект 2.


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

4.5 Выводы по анализу изменений в проектах после внедрения Agile


методологии в крупной Retail компании

В проекте 1 общее количество ошибок после принятия Agile было в три


раза больше, чем до применения Agile. Это объясняется тем, что до внедрения
Agile комплексная разработка системы не проводилась, а вместо этого был
27
проверен практический прогресс. Часто люди начинали использовать
фреймворк более активно, чем раньше, они начинали называть больше
функций. В результате было обнаружено несколько дефектов, которые не были
обнаружены в процессе тестирования.
Общее количество мероприятий по разработке нового функционала с
момента внедрения Agile стало больше, чем до применения agile-подхода. Это
связано с тем, что в момент принятия решения о переходе на Agile был создан
"пузырь" задач и что, выполнив Agile, все задачи, которые ранее только что
были решены, были занесены в бэклог.
Расчетное общее количество задач с момента внедрения Agile
увеличилось, так как общее количество задач-это количество ошибок и задач по
созданию нового функционала, и этот показатель также увеличился.
В проекте 2 Общее количество заданий для всех форм было меньше, чем
при внедрении Agile. Это связано с тем, что код отлажен, надежен и
продолжает полностью выполнять требования пользователя, а пользователи не
предпринимают действий по созданию новых функций. Описание полученных
результатов приведено в таблице 34.
Таблица 5.1 Итоги введения Agile [10]

Проект Среднее Среднее количество заданий на создание Среднее общее количество


количество новых функций на день заданий на день
ошибок на день
1 Увеличилось Увеличилось Увеличилось
2 Сократилось Сократилось Сократилось

В таблице 35 цели и преимущества внедрения Agile в крупном розничном


бизнесе сопоставляются с результатами опроса, проведенного для настоящего
отчета. Есть вариации с целями, которые имеют самые высокие цели. Ни одно
из преимуществ внедрения Agile в крупном розничном бизнесе не отражает
результатов опроса, проведенного для данного отчета.
Таблица 5.2 Сопоставление целей и преимуществ от введения Agile в
огромной международной Retail корпорации с ответами, которые были

28
получены в рамках работы «Анализ использования Agile в Retail на практике»
[10]

Приоритет целей Цели введения Agile в Цели введения по данным работы Совпадение
введения Agile большой Retail корпорации «Анализ использования Agile в Retail
на практике»
1. Увеличить скорость Увеличить скорость создания/ Да
создания продукта поставки продукта
2. Улучшить качество Получить возможность работать с Нет
создания продукта изменяющимися приоритетами
3. Увеличить Увеличить удовлетворенность Да
удовлетворенность клиента клиента
4. Ясность в ведении проекта Увеличить ясность ведения проектов Да
5. Манипулирование Улучшить мотивацию команды Нет
изменяющимися
приоритетами
6. - Улучшить качество продукта Нет
7. - Понизить проектные риски Нет
8. - Понизить расходы Нет
Приоритет Цели введения Agile в Цели введения по данным работы Совпадение
преимуществ большой Retail корпорации «Анализ использования Agile в Retail
введения Agile на практике»
1. Ясность в ведении проекта Возможность управлять Нет
изменяющимися приоритетами
2. Улучшение качества Увеличение скорости создания Нет
создания продукта продукта
3. Увеличение скорости Ясность ведения проектов Нет
создания продукта
4. Манипулирование Увеличение удовлетворенности Нет
изменяющимися клиента
приоритетами
5. Увеличение Улучшение качества итогов проектов Нет
удовлетворенности клиента
6. - Уменьшение проектных рисков Нет
7. - Увеличение точности планирования Нет
8. - Уменьшение цены на создание Нет
продукта

29
ЗАКЛЮЧЕНИЕ

Данная работа посвящена изучению функционального использования


Agile методов в розничном бизнесе.
В результате проведенного анализа были выявлены особенности
разработки и исполнения Agile: проблемы, методологии, инструменты. В
работе рассматриваются кейсы розничных предприятий, принявших Agile,
анализируются и очерчиваются ключевые моменты, достигнутые организацией,
а также составляется итоговая таблица эффективности Agile для
рассматриваемых компаний. К ним относятся: экономия затрат, подготовка к
ускоренному переходу, сокращение сроков производства, увеличение доли
рынка, ориентация на клиента и повышение лояльности клиентов и т. д. В
рамках функциональной части итоговой аттестационной работы был проведен
опрос гибких экспертов. На основе результатов исследования были выявлены
причины внедрения, проблемы, возникшие в ходе внедрения, преимущества,
полученные от гибкого подхода, и оценка полезности гибкой методологии для
розничного сектора. Результаты опроса выявили пробелы в приоритетах,
преимуществах и препятствиях между розничной торговлей и ИТ. В данной
работе были решены задачи исследования рынка крупного розничного бизнеса,
30
определения его функции и оценки улучшений в программах с момента
внедрения Agile-фреймворка. Руководство группы было убеждено в
необходимости трансформации организационной практики и согласилось
начать фокусироваться на внедрении адаптивных методологий управления
проектами.
Был проверен вывод об эффективности гибкого подхода в розничных
компаниях и о положительном влиянии гибкого подхода на оптимизацию
затрат и способность быстро адаптироваться в розничных компаниях.

СПИСОК ЛИТЕРАТУРЫ

1) Agile-манифест разработки программного обеспечения.


2) Agile Методы Снижают Стоимость Проекта.
3) Гандомани Ти Джей, Зулзалил Х. Международный журнал
программной инженерии и ее приложений. Как человеческие аспекты влияют
на переход и внедрение гибкой разработки программного обеспечения, 2014.
4) Отчет о состоянии Агиль.
5) Желязков Г. Гибкая цепочка поставок: анализ кейсов Зара / / личный
сайт, 2011.
6) Ли Кайфэн Динамичная цепь поставок, управление наукой и техникой
ISSN 1913-0341 Vol. 3 No. 2, 2009.
7) Дэмиен Дж. Пауэр, Амрик С. Сохал, Шамсур Рахман Критические
факторы успеха в гибком управлении критическими цепочками поставок
эмпирическое исследование, Международный журнал физического
распределения и логистического менеджмента, Vol. 31 Issue: 4, 2001. С. 147-
205.
8) Официальный сайт компании Билетрикс.
9) Мишин A. Как провести соревнование между проектными Агиль-
31
командами и увеличить производительность на 80% // Российский интернет-
форум «РИФ+КИБ», 2017.
10) Сазерленд Дж., Сазерленд Дж. Дж. Скрам: Искусство делать вдвое
больше работы за половину времени. Валюта. 2014.
11) Толоколников А. От Вотерфол к Агиль. Как эффективно управлять
разработкой сайта на аутсорсинге // Российский интернет-форум «РИФ+КИБ»,
2017.
12) Ротонди З. Отношения банковских и организационных моделей:
новая структура для UniCredit Group в Италии. BANCARIA, 4, 2013. С. 25-34.
13) Шальнова E. Мобильный банк Mobile.UniCredit. Опыт внедрения
методологии Скрам // Семинар «BSS Group», 2015.
14) Полуенктов A. Зачем нам Agile // Семинар Ассоциации Развития
Корпоративной Архитектуры «Агиль в крупных организациях», 2016.
15) Фишер Дж., Конинг Д., Людвигсен A.П. Использование atlassian jira
для управления крупномасштабной разработкой программного обеспечения,
2013.

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

33