ВКР: создание AGIL методологии разработки ПО для реализации e-commerce приложений в «Т-СИСТЕМС РУС»

1.

Санкт-Петербургский государственный электротехнический университет
«ЛЭТИ» им. В.И.Ульянова (Ленина)
(СПбГЭТУ «ЛЭТИ»)
09.04.02 Информационные системы и
Направление
технологии
Программа
Управление IT проектами и продуктами
Факультет
КТИ
Кафедра
АПУ
К защите допустить
Зав. кафедрой
к.т.н., доцент.
Шестопалов М.Ю.
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
МАГИСТРА
Тема: СОЗДАНИЕ AGILE МЕТОДОЛОГИИ РАЗРАБОТКИ ПО ДЛЯ
РЕАЛИЗАЦИИ E-COMMERCE ПРИЛОЖЕНИЙ
В КОМПАНИИ «Т-СИСТЕМС РУС»
Студент
Ляховец В.М.
подпись
Руководитель
Консультанты
ПО
ГОСТ и ЕСКД
Писарев А.С.
к.т.н., доцент.
(Уч. степень, уч. звание)
подпись
Власенко С.В.
к.т.н., доцент.
(Уч. степень, уч. звание)
подпись
Белаш О.Ю.
к.т.н., доцент.
(Уч. степень, уч. звание)
ЭО
подпись
Ширяева Т.П.
к.э.н., доцент.
(Уч. степень, уч. звание)
подпись
Санкт-Петербург
2017

2.

ЗАДАНИЕ
НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ
Утверждаю
Зав. кафедрой АПУ
доц., к.т.н. Шестопалов М.Ю.
«___»______________2017г.
Студент
Ляховец В.М.
Группа 1372
Тема работы: Создание agile методологии разработки по для реализации ecommerce приложений в компании «Т-Системс РУС»
Место выполнения ВКР: ООО «Т-Системс РУС»
Исходные данные (технические требования):
Предложить и внедрить методологию разработки ПО для реализации ecommerce продуктов
Содержание ВКР:
1. Теоретические аспекты рассматриваемой области
2. Анализ текущего состояния процессов разработки ПО в ООО «ТСистемс РУС»
3. Разработка Agile методологии разработки ПО
4. Внедрение новой методологии
Перечень отчетных материалов: пояснительная записка, презентация.
Дополнительные разделы: Составление бизнес-плана по коммерциализации
результатов НИР магистранта
Дата выдачи задания
Дата представления ВКР к защите
«01» апреля 2017 г.
«___»______________20___ г.
Студент
Руководитель
Ляховец В.М.
к.т.н. доцент
Писарев А.С.
(Уч. степень, уч. звание)
2

3.

КАЛЕНДАРНЫЙ ПЛАН ВЫПОЛНЕНИЯ
ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ
Утверждаю
Зав. кафедрой АПУ
доц., к.т.н. Шестопалов М.Ю.
«___»______________20___ г.
Студент(ка)
Ляховец В.М.
Группа 1372
Тема работы: Создание agile методологии разработки по для реализации
e-commerce приложений в компании «Т-Системс РУС»
№
Срок
Наименование работ
п/п
выполнения
1
Обзор литературы по теме работы
30.01-14.02
2
15.02-12.03
3
Анализ текущего состояния процессов разработки ПО в
ООО «Т-Системс РУС»
Разработка новой Agile методологии разработки ПО
4
Внедрение новой методологии
03.04-04.05
5
Оформление пояснительной записки
05.05-18.05
6
Оформление иллюстративного материала
19.05-21.05
Студент
Руководитель
13.03-31.03
Ляховец В.М.
к.т.н. доцент
Писарев А.С.
(Уч. степень, уч. звание)
3

4.

Реферат
Объём пояснительной записки – 90 страниц.
Пояснительная записка содержит 18 рисунков, 7 таблиц.
Ключевые
слова
-
Методология
разработки
ПО,
электронная
коммерция, компания ООО «Т-Системс РУС», Agile, Scrum, e-commerce.
Объектом исследования являются процессы разработки e-commerce
приложений.
Цель работы – создание методологии разработки ПО, наиболее
подходящей для крупных проектов, создающих e-commerce продукты.
В данной выпускной работе исследовались процессы разработки
программного обеспечения для e-commerce сферы. В результате анализа
была выявлена проблема выбора методологии разработки ПО, которая бы
максимально соответствовала всем особенностям e-commerce разработки.
Был выбран один из e-commerce проектов компании ООО «Т-Системс РУС»
для анализа хода разработки ПО. На основе процессов разработки в проекте
был сформирован список требований к методологии разработки e-commerce
приложений.
Предложенные
нововведения
и
изменения
в
процессе
разработки e-commerce продуктов легли в основу новой методологии
разработки
ПО,
которая
базируется
на
Scrum и
является
гибкой
методологией. Данная методология была внедрена в один из e-commerce
проектов компании ООО «Т-Системс РУС».
После анализа в течение 12 недель были получены результаты о
применении новой методологии разработки ПО для e-commerce продуктов.
4

5.

Abstract
The main aim of this qualifying work is the creating of software
development methodology for the implementation of e-commerce applications.
At the first stage of the work the modern software development
methodologies and the development of e-commerce applications were studied.
After that the process of development at T-Systems company was investigated.
Some proposals, changes and innovations for the development of e-commerce
applications were formed. A new methodology was created according them.
The final part was – the applying of new methodology at real project in TSystems. It was done successfully.
5

6.

Содержания
Определения ............................................................................................................ 8
Введение ................................................................................................................... 9
1. Теоретические аспекты рассматриваемой области ..................................... 11
1.1.
Разработка приложений электронной коммерции .......................... 11
1.1.1. История e-commerce ........................................................................... 11
1.1.2. Понятие электронной коммерции ..................................................... 13
1.1.3. Современное состояние и прогнозы на будущее e-commerce........ 14
1.1.4. Создание e-commerce IT продуктов .................................................. 16
1.2.
Сравнение e-commerce платформ...................................................... 18
1.3.
Методологии разработки ПО ............................................................. 23
1.3.1. Каскадная методология разработки ПО ........................................... 25
1.3.2. Инкрементная методология разработки ПО .................................... 27
1.3.3. Итеративная методология разработки ПО ....................................... 28
1.3.4. Спиральная методологии разработки ПО ........................................ 30
1.3.5. Гибкие методологии разработки ПО ................................................ 31
1.3.6. Scrum как одна из разновидностей Agile методологий .................. 33
1.4.
Выбор методологии разработки ПО ................................................. 35
2. Анализ текущего состояния процессов разработки ПО в ООО «Т-Системс
РУС» ....................................................................................................................... 40
2.1.
О компании ООО «Т-Системс РУС» ................................................ 40
2.2.
Применение Scrum методологии в проектах компании ................. 41
2.3.
Ключевые особенности разработки e-commerce приложений ....... 44
2.4.
Методологии разработки ПО для e-commerce приложений .......... 49
2.5.
Применение Scrum в проекте «Phoenix» .......................................... 51
2.5.1. Роли в проекте «Phoenix» ................................................................... 53
6

7.

2.5.2. Артефакты Scrum в проекте............................................................... 54
2.5.3. Процессы Scrum в проекте «Phoenix» .............................................. 56
2.6.
Недостатки в процессе разработки в проекте «Phoenix»................ 60
3. Разработка Agile методологии разработки ПО ............................................ 62
3.1.
Определение требований к новой методологии .............................. 62
3.2.
Изменение и нововведения в проекте ............................................... 63
3.2.1. Структурные изменения в команде................................................... 63
3.2.2. Изменения в процессе разработки .................................................... 65
3.3.
Описание новой методологии ........................................................... 69
4. Внедрение новой методологии ...................................................................... 72
4.1. Внедрение методологии в проекте «Phoenix» ................................. 72
4.1.1. Внедрение структурных изменений.................................................. 72
4.1.2. Внедрение изменений в процессах разработки ............................... 73
4.2.
Оценка экономической и временной выгоды использования
методологии ........................................................................................................... 74
4.3.
Сравнение разработанной методологии со Scrum........................... 75
4.4.
Преимущества и недостатки .............................................................. 76
5. Составление бизнес-плана по коммерциализации результатов НИР
магистранта ............................................................................................................ 78
5.1.
Концепция
технико-экономического
обоснования
разработки
проекта
............................................................................................................... 78
5.2.
Трудоемкость и календарный план выполнения работы ............... 79
5.3.
Смета затрат на выполнение разработки проекта ........................... 80
Заключение ............................................................................................................ 89
Список использованных источников .................................................................. 90
7

8.

Определения
В настоящей пояснительной записке применяют следующие термины с
соответствующими определениями:
B2B - Business-to-Business, взаимоотношения между коммерческими
организациями
B2C - Business-to-Consumer, взаимоотношения между коммерческой
организацией и потребителями
e-commerce - Электронная коммерция
FAQ - Часто задаваемые вопросы
IT- Информационные технологии
Scrum - Методология гибкой разработки ПО
ПО – Программное обеспечение
8

9.

Введение
Современный мир тяжело представить без сети Интернет, онлайнсервисы вторгаются в привычную жизнь людей и делают её легче и удобнее.
Одной из повседневных потребностей является покупка различных товаров в
магазинах. И даже эта сфера деятельности человека постепенно переходит в
Интернет.
За несколько последних десятков лет образовался огромная сфера
экономики - электронная коммерция или, называемая иначе, e-commerce.
Электронная коммерция включает в себя много областей: электронная
торговля, интернет-деньги, интернет-банкинг и многое другое. Электронная
торговля в интернете развивается очень активно, если ещё недавно только
первые интернет-магазины открывались, то сейчас их огромное количество.
Ежегодно прирост составляет около 20%, и самое интересное – рынок ecommerce только начинает развиваться, то есть, в скором будущем будет
развиваться ещё активнее. Уже сейчас в развитых странах интернет-продажи
составляют 10-12% от общего числа всех продаж.
За такой быстрой динамикой развития рынка нужно успевать
информационным технологиям. Нужно создавать большое количество
интернет-магазинов,
но
несмотря
на
скорость,
они
должны
быть
высококачественными, стабильными и отказоустойчивыми, так как работают
с реальными финансовыми, а также программное обеспечение должно
справляться с огромным количеством пользовательских запросов. Одним из
изящных решений всех перечисленных проблем и трудностей является
использование e-commerce платформ.
E-commerce платформа представляет собой некий «каркас», на основе
которого создаётся интернет-магазин. Все часто используемые части
функционала уже реализованы. Остаётся только реализовать какие-то
особенности, специфичные для конкретного бизнеса. С помощью e-commerce
платформ можно создавать интернет-магазины быстрее и дешевле.
9

10.

Разработка интернет-магазинов, особенно на e-commerce платформе,
имеет ряд особенностей, которые нужно учитывать при выборе методологии
разработки ПО для оптимального управления разработкой интерне-магазина.
В мировой практике гибкие методологии разработки ПО являются
предпочтительными для e-commerce продуктов, но и они не учитывают
особенностей e-commerce разработки. Поэтому существует актуальная
проблема выбора методологии разработки ПО, применимой для e-commerce
проектов. Поэтому целью данной работы является создание методологии
разработки ПО, наиболее подходящей для крупных проектов, создающих ecommerce продукты.
Для достижения поставленной цели необходимо решить следующие
задачи:
-
рассмотреть
и
изучить
особенности
разработки
e-commerce
приложений;
- проанализировать различные методологии разработки ПО и их
применимость для e-commerce разработки;
- рассмотреть процессы разработки в одном из e-commerce проектов
ООО «Т-Системс РУС»;
- описать возможные улучшения и нововведения в e-commerce проекте;
- на основе описанных улучшений формально описать новую гибкую
методологию для e-commerce проектов;
- внедрить разработанную методологию в e-commerce проект;
- проанализировать ход разработки в проекте после внедрения новой
методологии, сделать выводы.
10

11.

1. Теоретические аспекты рассматриваемой области
В данной главе рассматриваются особенности разработки e-commerce
информационных систем. Излагаются современные тенденции в разработке
ПО. Приводятся описания различных методологий разработки ПО.
1.1.
Разработка приложений электронной коммерции
Электронная коммерция, или, как по-другому называют, интернетторговля, – это вид коммерческой деятельности, для осуществления которой
используется всемирная сеть Интернет, и большая часть операций
происходит при помощи компьютера и компьютерных сетей. Также
употребляется другой англоязычный термин «e-commerce».
1.1.1. История e-commerce
Электронная коммерция зародилась в далёком 1960 году, когда
компании American Airways и IBM договорились о создании автоматической
системы регистрации пассажиров (SABRE). Система SABRE (Semi-Automatic
Business Research Environment) сделала перелёты более доступными для
обычных рядовых пассажиров, помогая им иметь актуальную информацию о
тарифах и рейсах, число которых возрастало постоянно. Благодаря
автоматическому процессу расчёта тарифов при резервировании мест в
самолёте
снизилась
стоимость
услуг
аэроперевозчика,
выросли
пассажироперевозки.
Совместный проект American Airlines и IBM — самый первый пример в
истории электронной коммерции. Изначально такая электронная коммерция
велась с использованием сетей, не входящих в сеть Интернет, по
специальным стандартам и каналам электронного обмена цифровой
информации между организациями, так как сети Интернет ещё не
существовало.
11

12.

К концу 60-х годов прошлого века в США существовало четыре
промышленных стандарта для обмена данными и цифровой информацией в
различных транспортных и логистических компаниях. Для объединения
данных стандартов в 1968 г. был создан Комитет согласования транспортных
данных, его результаты работы в дальнейшем легли в основу совершенно
нового EDI- стандарта.
В 1970-е годы схожие события происходили и в Великобритании. В
этой стране главной сферой применения EDI был не транспорт и логистика, а
торговля. Европейской экономической комиссией ООН была принята
спецификация
Tradacoms
в качестве стандарта обмена данными и
информацией в международных торговых организациях.
В начале 1980-х годов активно начались работы по объединению
американских и европейских стандартов. В результате данной в сентябре
1996 г. была принята Рекомендация № 25 «Использование стандарта
Организации Объединенных Нации для электронного обмена данными в
управлении, торговле и на транспорте».
В 1990-х годах появился стандарт EDI-FACT, принятый ISO, но
окончательное слияние европейского и американского стандартов не было.
Для обмена данными и информацией появилась на тот момент новая и
перспективная возможность – обмен данными через сеть Интернет. Активное
развитие сети Интернет с его низкой себестоимостью передачи данных
изменило и рынок электронной коммерции. В результате чего в середине
1990-х годов был разработан еще один новый стандарт – EDIFACT over
Internet (EDIINT), который описывал, как передавать EDI – транзакцию по
протоколам безопасной электронной почты SMTP/S-MIME.
Наиболее активно рынок e-commerce развивается в течение последних
20 лет, что объясняется следующими причинами:
12

13.

1. Очень стремительный рост количества интернет-пользователей по
всему миру, особенно в развивающихся странах
2. Увеличение влияния социальных сетей и других онлайн-платформ
3. Активное развитие систем электронных платежей
4. Переход основных игроков рынка к новым технологическим
платформам для электронной коммерции (от Web 1.0 к Web 2.0,
далее к Web 3.0).
1.1.2. Понятие электронной коммерции
Электронная коммерция – это вид коммерческой деятельности по
продвижению и продаже товаров и услуг от производителя к потребителю
через компьютерные сети и всемирную сеть Интернет. Иначе говоря,
электронная коммерция является маркетингом, приобретением и продажей
товаров и услуг через сеть Интернет. E-commerce предоставляет новые и
дополнительные возможности для повышения качества и эффективности
коммерческой деятельности.
В отличие от обычной и традиционной оффлайн коммерции
электронная коммерция предоставляет возможности:
- Продажа продукции через сеть Интернет;
- Развитие и координирование отношений с потребителями и
поставщиками;
- Обмен товарами и услугами в сети Интернет;
- Уменьшение цены на доставку цифровых продуктов и на
послепродажную поддержку покупателя;
- Быстрое реагирование на изменения рынка;
- Снижение накладных расходов;
13

14.

- Улучшение обслуживания клиентов и внедрение собственных
сервисов для покупателей;
- Расширение круга потребителей;
- Учёт индивидуальных нужд покупателя;
Покупателям e-commerce позволяет:
- Покупать нужный товар в любом месте и в любое время;
- Можно проводить сравнительный анализ товаров и услуг;
- Можно получить огромный выбор товаров в различных магазинах;
- Выбирать лучший для себя механизм совершения покупок;
- Получать актуальные новости и информацию в зависимости от своих
предпочтений.
1.1.3. Современное состояние и прогнозы на будущее e-commerce
Рынок e-commerce в мире и в России очень динамично развивается, не
смотря на негативные явления, такие как кризис и другое. В мире в течение
года средние темпы роста по данным компании eMarketer составляют
примерно около 18-20% в год. В России, в свою очередь, показатели
несколько ниже и составляют 17-18%. Это приблизительно 3-4% от общего
количества продаж в России и до 10-12% в США и других высокоразвитых
странах. Среднемировой уровень составляет приблизительно 6%. Самое
интересное то, что рынок e-commerce находится в стадии зарождения. По
некоторым прогнозам, доля e-commerce в общем количестве продаж
достигнет 20% в ближайшие годы. Для компаний, которые занимаются
продажами, игнорирование данного рынка сегодня значит смерть завтра.
На рисунке 1 представлен график роста объёмов продаж e-commerce.
14

15.

Рынок e-commerce (суммы в трлнх дол.)
2,5
2,357
2,053
2
1,771
1,505
1,5
1,251
1,058
1
0,5
0
2012
2013
2014
2015
2016
2017
Рисунок 1 – Развитие рынка e-commerce
В мировом масштабе быстрее всех показывают динамику роста
развивающиеся страны: Россия, Китай, Бразилия, Индия, Индонезия,
Мексика, Аргентина и многие другие. По динамике роста рынка e-commerce
в
процентном
соотношении,
лидерство
у развивающихся
стран, и
постсоветские страны относятся к последней группе. А это означает, что
рынки этих стран быстрее всего масштабируются и растут, хотя при этом
население стран не самое богатое.
Основную долю рынка e-commerce в мире составляет электроника (в
том числе и мобильные телефоны, компьютеры и др.), одежда, обувь и
аксессуары. Доля этих товаров в России доходит до 50%. В развитых странах
немногим меньше, 40-45%. Также люди в Интернете очень часто покупают
книги, товары для дома и офиса, мебель и некоторые другие товары.
Продукты питания, напитки и автозапчасти являются одними из самых
быстрорастущих сегментов продаж в Интернете по данным компании
eMarketer.
15

16.

1.1.4. Создание e-commerce IT продуктов
Как говорилось ранее, e-commerce рынок постоянно растёт, с каждым
днём интернет магазинов становится всё больше и больше, выбор и
разнообразие товаров так же увеличивается. Интернет-магазины являются не
только каталогами товаров, их функциональные возможности позволяют
оплачивать товар, автоматически оформлять доставку, взаимодействовать с
другими системами и многое другое. Соответственно, увеличивается
сложность разработки ПО для веб-магазина, зачастую приходится создавать
такую часть функционала, который используется почти во всех интернетмагазинах. Поэтому проще создавать новый интернет-магазин на основе
некоторого
каркаса,
с
уже
реализованными
часто
используемыми
функциональными возможностями.
Основой для разработки крупного веб-магазина является e-commerce
платформа, с помощью которой он разрабатывается. E-commerce платформы
являются основополагающим фундаментом бизнеса в сети Интернет, именно
они позволяют совершать онлайн-транзакции в Интернете. В быстро
меняющемся мире многосторонней розничной торговли это может быть
решением, с помощью которого можно управлять бизнесом в будущем.
Согласно
определению,
платформа
e-commerce
-
это
программное
обеспечение, которое позволяет совершать транзакции в сети Интернет. Но
вскоре e-commerce платформы стали включать в себя гораздо больше
функциональных
возможностей,
и
являются
теперь
сложными
всеохватывающими онлайн-решениями для розничной торговли в Интернете.
Важно понимать, что одни из необходимых частей функциональности
платформы - это возможность интеграции и взаимодействия с другими
системами, такими как Enterprise Resource Planning (ERP), логистика и
системы выполнения. Некоторые функциональные возможности, которые,
возможно,
считались
не
частью
e-commerce
16
платформы,
например

17.

информационные бюллетени (PDF файлы рассылок на электронную почту),
маркетинговая статистика, теперь также включаются в состав платформы.
Любая
e-commerce
платформа
предоставляет
следующие
функциональные возможности:
- Все ключевые компоненты e-commerce, таких как управление
корзинами покупок, каталоги продуктов и процессы расчетов, необходимые
для электронной коммерции (B2B) и схемы бизнес-потребитель (B2C);
- Предоставление пользователям Web 2.0 Rich Internet Application (RIA)
инструментов для покупок, таких как слайдеры для поиска и заказа в один
клик, а также возможность использовать созданный пользователями контент,
такой как обзоры продуктов, вики-страницы и блоги;
- Использование внешних веб-сервисов (например, Google Maps,
Google Analytics) и внутренних веб-службы (таких, как системы выполнения,
ERP или веб-службы, основанные на колл-центре), чтобы осуществлять
работу с клиентами;
- Интеграция с мобильными телефонами, мобильные приложения;
- Поддержка множества форм оплаты для B2B и B2C продаж;
- Предоставление рекомендации по продукту или услуге в режиме
реального времени;
- Улучшенный поиск по сайту и внешнюю поисковую систему
(например, Google, Bing, MSN, Яндекс или Yahoo);
- Персонализация пользовательского аккаунта.
- Предложение подходящих моделей использования, таких как
лицензионное программное обеспечение, услуги веб-хостинга, программное
обеспечение как услуга (SaaS), аутсорсинг и программное обеспечение с
открытым исходным кодом (OSS);
17

18.

- Большой набор технологических и сервисных партнеров широкого
спектра.
1.2.
Сравнение e-commerce платформ
При изучении платформ электронной коммерции для розничных
продавцов предлагается множество решений, начиная от премиальных
корпоративных решений, стоимость которых может составлять от десятков
до сотен тысяч долларов, до решений, которые являются бесплатными.
Однако такие бесплатные решения могут требовать высокого уровня
технических навыков и опыта людей, которые будут заниматься разработкой
и поддержкой ПО на их основе. Учитывая это и тот факт, что платформа ecommerce является основой любого онлайн-магазина, найти правильное
решение, которое соответствовало требованиям конкретного розничного
бизнеса, а также могло интегрироваться с существующими системами и
удовлетворять потребности клиентов, является сложной задачей.
При выборе платформы e-commerce нужно учитывать многие факторы
для различных заинтересованных сторон:
- заинтересованность розничного продавца-заказчика заключается в
поиске платформы, которая включает в себя функции, которые он хочет,
чтобы платформа была не слишком технически сложна в использовании и
предлагала достойные возможности для обучения и её поддержки;
- дизайнер ищет платформу, которая поддерживает последние и самые
лучшие решения веб-дизайна;
- для разработчика важно найти e-commerce платформу, с которой ему
интересно и продуктивно работать, скорее всего, платформа с открытым
исходным
кодом
и
проприетарные
платформы
разработчиков больше;
18
будут
интересовать

19.

- служба поддержки заинтересована в поддерживаемой системе,
которая
будет поддерживать новейшие
технологии
браузера, иметь
мобильные возможности и новейшую защиту от хакеров и мошенников, как
правило, всё это связано с масштабируемостью и ремонтопригодностью всей
системы.
Первой рассматриваемой e-commerce платформой является IBM
WebSphere Commerce. Включает в себя несколько решений.
IBM WebSphere Commerce Enterprise - это интерактивная платформа,
предназначенная для оптимизации процессов по нескольким каналам продаж
и поддержки нескольких сайтов. Данное решение может запускать сайты
B2C по нескольким брендам, сегментам и странам.
IBM WebSphere Commerce Professional - это комплексная кроссканальная платформа для компаний среднего размера, служит для
предоставления персонализированных и многоканальных покупок. Эта
версия включает мерчандайзинг товаров, настраиваемые бизнес-процессы,
многовариантное тестирование, оптимизацию поисковых систем и функции
персонализации.
IBM WebSphere Commerce Express предназначена для предприятий
малого и среднего бизнеса и предлагает решение, помогающее растущим
компаниям вести бизнес в Интернете.
Конкурентом предыдущей платформы является Oracle ATG Web
Commerce. Данная платформа - это ведущее в отрасли решение для ecommerce, которым пользуются лучшие мировые бренды. ATG Web
Commerce
обеспечивает
единообразную
персонализированную.
кросс-
канальную работу с клиентами. ATG Web Commerce позволяет работать
продавцу с покупателями, в том числе в Интернете, контакт-центре,
мобильных устройствах, социальных сетях, магазинах и т. д. Данную
платформу используют более половины интернет-магазинов из ТОП-100
19

20.

мировых лидеров по продажам в сети Интернет. Важно понимать, что данное
решение выбирают очень крупные интернет-магазины, мировые лидеры,
которым требуется большой набор возможностей для розничной торговли.
Особенностью данной платформы является очень гибкий и удобный
механизм работы со скидками: существует возможность задавать правила на
разных уровнях в иерархии товаров (скидка только на товар, на заказ в целом
или на доставку). Скидка определяется в зависимости от количества товаров,
по цене, по времени покупки и по разным другим критериям.
ATG
Web
Commerce
предоставляет
возможность
работы
со
сценариями. Для повышения объемов продаж существует функциональность,
которая настраивает специальные сценарии для поддержки процессов
покупки, выходящих за стандартные модели поведения пользователя.
Например, пользователь зарегистрировался в интернет-магазине, выбрал себе
товар, положил его в корзину, но потом покинул интернет-магазин и не
заходил на его страничку несколько дней, в этом случае можно настроить
следующий сценарий – на его электронную почту придёт сообщение с
напоминаем об его товарах в корзине.
Ещё одна известная e-commerce платформа – SAP Hybris. Основанная в
1997 году, платформа Hybris предлагает многоканальное решение для
коммерческого программного обеспечения, которое интегрирует контент
продукта, коммерческие операции и расширенный набор каналов продаж,
чтобы помочь розничным продавцам продавать товар.
Ключевыми отличиями являются мощные инструменты управления
контентом продукта, управление каталогами, интеграция предприятий и
глобализация,
а
также
возможности
интернационализации,
четкая
способность расширять продукт и настраивать его под свои нужды.
Hybris обеспечивает управление рекламными предложениями, которые
включают купоны, личные предложения и подарочные карты. Также
20

21.

обеспечивает повышение количества продаж, анализируя профили клиентов,
и может предоставить доступ в режиме реального времени к поведенческой
базе пользователей.
В данной e-commerce платформе хорошо реализована поддержка
многосайтовых возможностей и локализованного контента, и ассортимента
продуктов.
Есть
многоязычность,
мультивалютность,
возможно
устанавливать локализованные цены и промо-акции в зависимости от
региона проживания пользователя, а также локализованные процессы
(расчеты налогов, правила и т. д.).
Последняя рассматриваемая e-commerce платформа – Magento. Она
является самой дешёвой из описанных выше, начала распространяться в 2007
году, когда появилась первая бета-версия платформы. Сначала половина
компании была выкуплена eBay, а потом и полностью. Magento считается
самой популярной e-commerce системой в мире, в том числе в сегменте
решений для крупных магазинов.
Magento предоставляет все необходимые возможности для интернетмагазина, такие как каталог товаров, возможность покупки, кроме этого
имеется большое количество модулей, которые можно подключить для
различных потребностей. Имеются возможности для многоканальной
продажи, поддерживается мультиязычность.
Magento включает в себя не только платное платное решение, но и
бесплатное сообщество разработчиков и версию Community, которую. с
помощью
модульной
структуры
платформы
можно
приспособить
практически под любые нужды большого интернет-магазина. Если у
магазина есть потребность расти и развиваться, то необходимый для этого
переход с бесплатной лицензии на коммерческую в рамках Magento не
займёт много времени и выльется большими потерями в финансовом плане.
21

22.

Сводная информация обо всех перечисленных e-commerce платформах
представлена в таблице 1.
Таблица 1 - Сравнение e-commerce платформ
Название
Основные возможности
IBM
Многоканальная продажа, большие
WebSphere возможности обзора продуктов,
Commerce управление
каталогами,
мерчендайзинг,
возможности
интеграции
со
сторонними
сервисами,
мобильные
приложения,
интеграция
с
социальными сетями
Oracle
Поддерживает
огромное
ATG Web количество пользователей, отлично
Commerce подходит для мульти язычных
магазинов,
большой
набор
возможностей для управления
скидками,
акциями,
сценарии
работы с пользователем, широкие
настройки персонализации.
SAP
Обработка
больших
объемов
Hybris
данных,
многоканальная
коммерция, гибкая архитектура,
поддержка нескольких сайтов,
готовые решения для мобильных
устройств,
средства
для
персонализации.
Magento
Больше
6400
встраиваемых
модулей, бесплатная версия для
небольших магазинов, огромное
сообщество разработчиков, единая
панель управления для нескольких
магазинов.
Цена
50,000$ в год
500 000 $ за
первый год,
110 000$ за
последующие
Основные
клиенты
Sears, City
Beach,
1800
Flowers,
Office
Brands,
Sony
Apple,
Dell, Nike,
Lego,
Летуаль,
М.Видео,
Tommy
Hilfiger
От 54 000 $ в Target,
год
H&M,
Lufthansa,
Douglas,
Reebok,
Ericsson
17 900 $ в год
Ted’s
Cameras,
Bing Lee,
Samsung,
Lenovo,
Philips,
Ашан,
Nestle
Ознакомившись с различными e-commerce платформами, можно
сделать вывод о том, что все системы схожи между собой, а также о том, что
22

23.

они отличаются лишь в некотором функционале, стоимости лицензий для
приобретения. Но это не совсем является действительностью.
Основным моментом в различии платформ является скорость
внедрения продукта на её основе. Это тот срок, за который проходит
зарождения проекта, реализация, внедрение.
Для каждого конкретного случая нужно проводить глубокий анализ
требований, также нужно принимать во внимание бюджет, располагаемые
ресурсы и временные рамки для создаваемого продукта.
В любом случае, приобретая одно из решений можно быть уверенным
в его качестве, ведь сегмент e-commerce платформ предполагает премиумпредложения, опыт использования и качество которых оттачивались годами.
1.3.
Методологии разработки ПО
Чтобы понять, что такое методология разработки ПО, нужно
сформулировать цели, без которых невозможно создание IT продукта..
Главной задачей любого успешного проекта является условие того, чтобы на
момент запуска системы и в течение всего жизненного срока можно было
обеспечить:
-
необходимую
функциональность
системы
и
изменяющимся требованиям к её функциональности;
- требуемое время отклика и реакции системы на запрос;
- требуемую пропускную способность ПО;
- простоту и удобство эксплуатации системы;
- способность поддерживать систему;
- отказоустойчивость системы в требуемом режиме;
23
адаптацию
к

24.

- требуемую безопасность.
Производительность системы - главный фактор, который определяет
эффективность ПО. Хорошее и продуманное проектное решение является
основой высоконагруженной и высокопроизводительной системы.
Проектирование информационных систем включает в себя три
основные области:
- проектирование непосредственно программ, различных элементов
графического интерфейса, отчетов, которые будут обеспечивать доступ к
данным;
- проектирование структур данных и баз данных;
- учет технологий и среды: топологии сети, использования различных
архитектур, конфигурации аппаратных средств, параллельной обработки
данных или распределенной обработки данных.
В реальных условиях коммерческой разработки ПО проектирование
информационных систем является поиском лучшего способа, который
обеспечивает
необходимые
функциональные
требования
к
системе
имеющимися к компании и с учетом ограничений, которые были заданы для
продукта.
Методология разработки ПО – это набор методов и правил, которые
используются для постановки задачи, планирования, реализации IT продукта.
Сам
процесс
разработки
описывается
моделью,
определяющей
последовательность этапов разработки и получаемых результатов.
На
протяжении
долгого
времени
процесс
разработки
ПО
осуществлялся в соответствии с методиками, разработанными в инженерной
области, то есть, это стандартизованная практика поэтапного создания IT
продукта. Процесс начинался с составления формальных спецификаций и
заканчивался поставкой продукта заказчику. Существуют стандарты,
24

25.

описывающие данный процесс: ГОСТ в России и ISO в Европе, CMM
(Capability Maturity Model — распространен в США), регламентирующие
данный процесс.
При
разработке
программного
продукта
используется
большое
количество методологий разработки ПО, иначе говоря, устоявшихся
подходов и наборов правил. Выбор зависит от специфики конкретного
проекта, бюджета, временных рамок, субъективных предпочтений и даже
темперамента и настроя руководителя. Далее будет дано описание наиболее
используемых методологий разработки в настоящее время.
1.3.1. Каскадная методология разработки ПО
Одной из самых популярных методологий разработки ПО является
каскадная методология или, как ещё её называют, waterfall. Она является
одной из самых старых методологий и подразумевает последовательное
прохождение стадий, каждая из которых должна завершиться полностью до
начала следующей. Схематически стадии разработки ПО представлены на
рисунке 2.
Рисунок 2 - Каскадная методология
25

26.

Если следовать каскадной модели, то разработчик должен переходить
от одной стадии к другой в строго определённом порядке. Сначала
полностью завершается этап «проектирование», в результате чего получается
список
требований
к
продукту,
планирование
бюджета,
времени,
технических деталей. После того как требования определены, происходит
переход к дизайну, в ходе которого создаются документы с описанием
архитектуры приложения, описываются элементы графического интерфейса.
После этого программисты приступают к реализации проекта. На следующей
стадии процесса производится тестирование и отладка созданного продукта;
на этой стадии устраняются все ошибки и недочёты, появившиеся на
предыдущей
стадии
разработки.
После
этого
ПО
внедряется
и
осуществляется его поддержка. Это может быть, как внесение новой
функциональности, так и устранение ошибок.
При использовании модели Waterfall легко управлять проектом.
Благодаря
её
жесткости
и
невозможности
отклонений
от
заранее
определённых рамок, разработка ПО проходит быстро, а стоимость и сроки
заранее определены. Но это является, как и преимуществом, так
одновременно и недостатком. Каскадная модель даёт отличный результат
только в проектах с заранее определенными требованиями и способами их
реализации. Нет возможности вернуться и что-то поменять в требованиях,
даже, если очень нужно. Тестирование продукта начинается только после
того, как разработка полностью завершена или почти завершена. Те
продукты, которые были разработаны по данной модели без обоснованного
ее выбора, могут иметь недочеты, так как список требований нельзя
скорректировать после разработки, о которых становится известно лишь в
конце, либо на стадии разработки или тестирования из-за строгой
последовательности действий. Так как требования определяются в начале, то
на этапе разработки или ещё позже их изменить очень проблематично.
Стоимость внесения изменений очень высока, так как для этого нужно ждать
26

27.

завершение проекта и начинать всё заново. Но тем не менее, фиксированная
заранее определённая стоимость часто перевешивает минусы подхода.
Конечно, исправление недостатков, которые были обнаружены позже,
возможно, только это требует подписания дополнительных соглашений к
контракту, что может быть весьма проблематично.
Каскадную методологию лучше использовать:
- только тогда, когда все требования к системе известны, понятны и
зафиксированы, а противоречивых требований не имеется;
- в относительно небольших и несложных проектах;
Нет проблем с доступностью программистов нужной квалификации.
1.3.2. Инкрементная методология разработки ПО
Инкрементная методология разработки - это методология разработки
программного обеспечения, где продукт разрабатывается, внедряется и
тестируется
постепенно
(каждый
раз
добавляется
некоторая
часть
функционала), пока продукт не будет полностью закончен. Инкрементная
методология включает в себя как разработку, так и обслуживание. Продукт
определяется как готовый, когда он удовлетворяет всем требованиям. Эта
методология сочетает в себе элементы модели водопада в цикле.
В инкрементной методологии управления полные требования к системе
делятся на различные сборки, системные пакеты. Имеются несколько циклов
разработки, а цикл, в свою очередь, разделен на более мелкие и легко
создаваемые части функционала. Каждая часть проходит через фазы
определения системных требований, проектирования, написания кода,
тестирования
и
внедрения.
Процесс
разработки
по
инкрементной
методологии предполагает выпуск на самом первом большом этапе продукта
в базовой ограниченной функциональности, а затем уже инкрементное
27

28.

добавление новых функций. Процесс продолжается до тех пор, пока не будет
создана полная система. На рисунке 3 – использование инкрементной
методологии разработки ПО.
Рисунок 3 – Инкрементная методология разработки ПО
Инкрементную методологию используют:
- требуется ранний вывод продукта на рынок;
- когда основные требования к системе определены и понятны, но
некоторые детали могут разрабатываться позже;
- имеется несколько рисковых функциональных требований.
1.3.3. Итеративная методология разработки ПО
Итеративная методология очень схожа с ранее рассмотренной
инкрементной методологией. Она применяется, если нет изначально
описанных требований к продукту. Начинается разработка с первой «сырой»
версии, она может быть неидеальна, главное, чтобы она работала.
28

29.

Основное отличие от инкрементной методологии показано на рисунке
4. Оно заключается в том, что инкрементная модель разработки направлена
на создание отдельных финальных и завершённых модулей системы с уже
работающим функционалом, в свою очередь, итеративная модель направлена
на создание версий ПО с последующим улучшением.
Рисунок 4 – Отличие инкрементной методологии от итеративной
Лучше всего использовать инкрементную методологию:
- если проект большой или очень большой;
- требования к конечной финальной системе заранее определены,
согласованы и понятны;
- основная задача продукта определена, однако конкретные детали
реализации могут изменяться в течение времени.
29

30.

1.3.4. Спиральная методологии разработки ПО
Спиральная методология похожа на предыдущую инкрементную, но с
большим акцентом на анализ рисков. Она хорошо подходит для решения
очень важных задач, например, если неудача несовместима с дальнейшей
деятельностью компании.
Каждый виток спирали (Рисунок 5 – Спиральная методология)
соответствует созданию какого-то ограниченного фрагмента или версии ПО,
на нём уточняются цели и различные характеристики проекта, планируются
работы следующего за ним витка спирали и определяется качество продукта.
Таким образом детализируется проект и в конечном счёте выбирается
обоснованное решение, которое и доводится до реализации.
Рисунок 5 – Спиральная методология
Главная задача, которая ставится в спиральной методологии — это как
можно
быстрее
показать
пользователям
и
заказчикам
системы
работоспособный продукт, пусть даже первую «сырую» версию, тем самым
начиная процесс уточнения и дополнения всех требований. Основной
проблемой спирального цикла является определение момента перехода на
следующий
этап
спирали.
Для
это
30
необходимо
ввести
временные

31.

ограничения на каждый из этапов спирали или жизненного цикла. Переход
осуществляется согласно плану, даже если ещё не вся намеченная работа
закончена. План составляется на основе статистических данных, которые
были получены в предыдущих проектах, и личного опыта разработчиков
Эта модель не подойдет для малых проектов, имеет смысл её
использовать, если проект дорогой и большой, допустим, таких, как
разработка ПО документооборота для большого банка, когда каждый
последующий шаг требует ещё большего анализа для оценки последствий,
чем
программирование.
Обычно
используется
в
государственном и
административном секторе, в больших проектах для всей страны, так как
большое
время,
потраченное
на
анализ,
компенсируется
большим
количеством пользователей.
1.3.5. Гибкие методологии разработки ПО
Гибкая методология разработки — это серия подходов и техник к
разработке ПО, которые ориентированы на использование динамического
формирования требований, итеративную разработку и обеспечение их
реализации в результате плотного общения и взаимодействия членов одной
команды, которые являются профессионалами различных направлений.
Существует много различных методологий, которые являются гибкими, в
частности Scrum, FDD, экстремальное программирование, DSDM и другие.
При использовании гибкой методологии разработки ПО после каждой
итерации заказчик (владелец продукта) может видеть результат работы и
понимать, принимает он его или нет. Это самое важное преимущество гибкой
методологии. А к ее недостаткам можно отнести то, что из-за отсутствия
чётко описанных формулировок результатов сложно оценить изначально
человеческие ресурсы, трудозатраты и стоимость, требуемые на разработку
ПО. Экстремальное программирование (XP) и Scrum являются одними из
31

32.

наиболее известных применений гибкой методологии разработки ПО на
практике.
Рисунок 6 – Гибкие методологии разработки ПО
Данная методология разработки ПО подходит для длительных и
больших проектов, постоянно адаптируемых к потребностям рынка.
Соответственно, в процессе реализации продукта ПО требования постоянно
меняются. Также методология подходит для класса творческих людей,
которые генерируют, выдают и пробуют новые идеи и мысли ежедневно или
даже ежечасно. Внутренние стартапы лучше разрабатывать, используя
гибкие методологии разработки ПО.
Основной метрикой и результатом гибких методологий является
рабочий продукт. При использовании данной методологии уменьшают объём
письменной документации по сравнению с другими методологиями. Это
приводит к критике этих методологий как недисциплинированных.
Используются гибкие методологии в следующих случаях:
- если изменения реализуются за меньшую стоимость из-за частых
инкрементов во время разработки ПО;
32

33.

- в отличие от водопадной модели в гибкой методологии для начала
проекта достаточно лишь небольшого планирования.
- когда потребности пользователей и заказчиков меняются.
1.3.6. Scrum как одна из разновидностей Agile методологий
Scrum является самой популярной и широко используемой Agile
методологией
разработки
ПО.
Важно
понимать,
что
Agile
–
это
спецификация методологий, а Scrum – конкретная реализация данной
спецификации, то есть набор конкретных правил и подходов.
Рисунок 7 – Разработка ПО используя Scrum
Работа по Scrum организована по следующим основным правилам
(рисунок 7):
- существует «владелец продукта» - это заказчик продукта или лицо
представляющее его, владелец продукта следит за постановкой задач и их
выполнением, тесно общается с командой;
33

34.

- работа выполняется в небольших кроссфункциональных командах,
состоящих из разработчиков, тестировщиков и других специалистов,
выделяется один человек – скрам-мастер, который отвечает за соблюдение
процессов в команде, коммуникацию между членами команды и другими
ответственными людьми, а также за конструктивную атмосферу;
- вся работа ведётся короткими (от 1 до 4 недель) фиксированными
итерациями - спринтами, в результате которых поставляется некоторый
конечный функционал, который можно даже вывести на рынок при
необходимости;
- все задачи, которые есть в проекте, записываются в порядке
приоритета в бэклог продукта;
- команда, оценивая свою скорость, набирает задачи на спринт,
который не изменяется во времени, и составляется бэклог спринта;
- каждый день проводятся скрам-собрания, на которых команда
синхронизирует свою работу, обсуждает текущий статус и проблемы;
- в процессе работы члены команды берут в работу элементы бэклога
спринта согласно приоритету задачи;
- в конце каждого спринта проводится обзор спринта, чтобы получить
обратную связь от владельца продукта, и ретроспективу спринта, чтобы
оптимизировать процессы работы в команде, каждый член команды отвечает,
что было хорошо, а что не понравилось;
- после этого владелец продукта может поменять требования или их
приоритеты и запустить новый спринт, выполняя все шаги заново.
Но Scrum не является единственной Agile-методологией, существует
огромное количество других методологий: Lean, Scrumban, экстремальное
программирование, Crystal Clear, Dynamic Systems Development Method, Agile
Unified Process, Feature-driven development, ICONIX, Канбан и многие другие.
34

35.

Часто используются различные комбинации гибких методологий. Кроме
того, на поздних этапах внедрения Scrum можно заимствовать разные
подходы из других гибких методологий. Компания Agile Survey (сообщество
Agile) проводила исследование о популярности гибких методологий,
результаты его представлены на рисунке 8
Рисунок 8 – Использование гибких методологий
Проанализировав диаграмму, можно с уверенностью сказать, что Scrum
– самая используемая гибкая методология.
1.4.
Выбор методологии разработки ПО
Проанализировав современное состояние методологий разработки ПО
можно сделать вывод, что самые используемые модели – это водопадная и
гибкие методологии. Даже в последнее время гибкие методологии
используются чаще в новых проектах. Важно понимать, что выбор
методологии – очень важный момент в разработке продукта. Нужно
35

36.

учитывать особенности конкретного создаваемого продукта, всех участников
и выбирать наиболее пригодную для проекта методологию.
Не существует универсального, подходящего всем проектам, набора
условий для всех ситуаций при выборе той или иной методологии разработки
ПО. В каждом конкретном случае нужно ориентироваться на специфику
данного проекта. Приведённая блок-схема на Рисунок 9 – Алгоритм выбора
методологии разработки ПО лишь обозначает ключевые аспекты выбора. Ни
в коем случае не нужно воспринимать данный алгоритм, как единственно
правильный по выбору методологии.
Рисунок 9 – Алгоритм выбора методологии разработки ПО
Выбрав конкретную методологию разработки ПО, не нужно полностью
следовать ей. Часто ее необходимо доработать, адаптировав под проект. Чтото можно исключить, а что-то можно добавить из других методологий или
внести что-то своё. Например, нормальной практикой считается парное
программирование в водопадной методологии, если это принесёт пользу
проекту. Например, существует огромное множество примеров применения
Scrum и Kanban в одном проекте.
36

37.

Будет рассмотрен алгоритм подробнее.
Первое условие – стартап ли это. Стартапы характерны тем, что в
начальный период, всё строится только на энтузиазме и идее. Если навязать
какую то методологию стартапу и поставить в определённые рамки, то либо
энтузиазм пропадёт, либо никто не будет соблюдать правила. В дальнейшем,
когда стартап вырастет, можно переходить к использованию какой-то
методологии.
Следующее условие – есть ли риски. Абсолютно каждый проект имеет
определённые риски, однако в данном случае имеются в виду риски очень
серьёзные, что заранее не понятно, возможно ли будет реализовать продукт.
Если такие риски есть, то необходимо начинать разработку с прототипа,
концепта, чтобы стало понятно, чтобы были ясны возможности реализации.
В данном случае оптимальной методологией является спиральная модель.
Третье условие – меняются ли требования. Если требования заранее
хорошо известны, и есть уверенность, что в процессе разработки заказчик их
не будет менять, то тогда следует выбрать каскадную методологию
разработки.
Следующий вопрос - сложные ли требования. Когда требования
сложные,
необходимо
очень
тщательно
продумывать
все
сценарии
тестирования, и на этапе проектирования разрабатывать подходы к
тестированию. В таком случае полезна методология V-Model, являющаяся
разновидностью каскадной методологии разработки ПО.
Ещё один важный вопрос - формализованный ли подход, заключается в
том, что все процессы жизненного цикла продукта очень детально
регламентированы. Это очень важно в сложных и больших проектах с
большим количеством участников в проекте.
Если требуется описанный формализованный подход, то можно
использовать такие методологии разработки как OpenUp, RUP, EssUp. Такие
37

38.

методологии есть нечто большее, чем просто методологии, это детально
описанные фреймворки процессов. Они изначально создавались для
итеративного подхода, но, их сейчас используются использовать и в
каскадной модели разработки ПО. Если формализованный подход не нужен,
тогда лучше всего использовать гибкие методологии разработки.
Качество или скорость важнее для продукта – следующий вопрос.
Если важно качество, то необходимо использовать практики экстремального
программирования, такие как парное программирование, разработка через
тестирование, непрерывная интеграция и многие другие. Особенностью
экстремального
программирования
является
то,
что
необходимо
использовать все 12 практик, только тогда эффект от них будет осязаемым.
Нужны ли постоянные улучшения – один из последних вопросов
алгоритма выбора. Если нужны улучшения в продукте, то лучше
использовать Scrum, так как он ориентирован на постоянное улучшение
процесса. Для этого есть ретроспективы, которые проводятся в конце
каждого спринта для выявления недостатков в работе над созданием
продукта.
Последний вопрос в алгоритме – о длительности. Методология RAD
имеет много общего гибкими методологиями, но есть существенное
ограничение на длительность проекта. Длительность должна быть небольшой
и ограничена 60-90 днями. Канбан подходит для проектов, которые длятся
очень долго, почти вечно. Также используется в проектах поддержки, но
плохо использовать там, где требуется разработать технически сложный
продукт, так как он ориентирован на быстрое добавление функциональных
деталей в приложение.
Разработка e-commerce приложений также имеет ряд технологических
особенностей, так как приложения создаются на основе e-commerce
38

39.

платформ, это нужно принимать во внимание при выборе методологии
разработки ПО для таких проектов.
39

40.

2. Анализ текущего состояния процессов разработки ПО в ООО «ТСистемс РУС»
В данном разделе будет дана информация о компании, где выполнялась
работа, а также будет проведён анализ существующих подходов к разработке
ПО в нескольких проектах компании, чтобы определить их достоинства и
недостатки.
2.1.
О компании ООО «Т-Системс РУС»
ООО «Т-Системс РУС» является стратегическим подразделением
немецкого концерна Deutsche Telekom, ООО «Т-Системс РУС» - один из
ведущих лидеров в сфере информационных и телекоммуникационных услуг
для таких отраслей производства, как автомобилестроение, промышленность,
транспорт, энергетика, нефтегазовая промышленность. ООО «Т-Системс
РУС» имеет офисы по всему миру, в более чем в 20 странах и более 50 000
профессионалов в сфере информационных технологий по всему миру.
ООО «Т-Системс РУС» предоставляет комплексные услуги и создание
технологических продуктов. Спектр услуг компании очень широк и
разнообразен:
начиная
от
проектирования,
консалтинга,
разработки,
интеграции и внедрения и заканчивая управлением жизненным циклом
приложений. Компания отлично показала себя как надежный поставщик,
обеспечивающий всестороннее и полное вовлечение всех имеющихся в
компании ресурсов и предлагающий индивидуальный подход к каждому
клиенту компании.
ООО «Т-Системс РУС» внедряет и управляет информационнокоммуникационными технологиями (ИКТ), благодаря своей всемирной и
глобальной инфраструктуре сетей и дата-центров. Компания ООО «ТСистемс РУС» работает во всех отраслях: начиная от автомобилестроения,
заканчивая
телекоммуникациями,
финансовым
40
сектором,
розничной

41.

торговлей, сферой услуг, СМИ, энергетикой и машиностроением, включая
государственные учреждения и здравоохранение.
Оборот компании ООО «Т-Системс РУС» в 2013 году составил более
10,02 млрд евро. В России компания ООО «Т-Системс РУС» работает
начиная с 1995 года. Сейчас её российское подразделение имеет головной
офис в Москве, а также офисы в Санкт-Петербурге, Воронеже и
Екатеринбурге.
ООО «Т-Системс РУС» специализируется на внедрении систем
управления
SAP,
разработке
и
поддержке
ПО,
предоставлении
телекоммуникационных услуги других ИКТ услуг, также включая cloudсервисы.
Среди заказчиков ООО «Т-Системс РУС» такие крупные российские и
международные компании, как ОАО «РЖД», НК «Лукойл», ОАО «Силовые
машины», концерны Shell, Royal Dutch, Daimler AG, Mercedes-Benz RUS.
Volkswagen AG, BMW AG, Henkel, Danone, Швейцарские железные дороги,
Мясоперерабатывающий
завод
КампоМос,
Международный
аэропорт
Шереметьево, Аэропорт Внуково.
ООО «Т-Системс РУС» имеет статус мирового сервис-партнера SAP,
глобального хостинг партнера SAP, глобального партнера SAP по поддержке
приложений, глобального партнера EMC, Microsoft, Intel, Cisco Systems.
2.2.
Применение Scrum методологии в проектах компании
Компания ООО «Т-Системс РУС» имеет основной офис разработки в
Санкт-Петербурге, где и выполнялась работа. В петербургском офисе ведётся
активная разработка более 120 проектов. В основном, это разработка
крупных веб-приложений на Java EE, также имеются проекты, связанные с
SAP разработкой и единичные проекты с другими технологиями.
41

42.

Компания имеет несколько подразделений, каждое из которых
занимается разработкой ПО для конкретной сферы деятельности, например,
существуют подразделение Automotive, которое занимается разработкой ПО
для автомобильной сферы. Самое большое подразделение – это Telekom IT,
данное подразделение занимается разработкой приложений для своей
дочерней компании – немецкому концерну Deutsche Telekom AG. В
большинстве своём разрабатываемые продукты предназначены для оказания
услуг мобильной связи, стационарной связи и покрытию интернета, а также
для внутреннего обеспечения и управления всеми сервисами. Deutsche
Telekom AG является внутренним заказчиком для компании ООО «ТСистемс РУС», в свою очередь другие компании – сторонние заказчики.
Нужно отметить, что в значительной части проектов не ведётся
активная разработка нового функционала, а осуществляется поддержка и
исправление ошибок в предыдущих версиях продуктов. И лишь небольшая
часть проектов является новыми (до 2 лет) для компании.
Все вышеперечисленные факторы играют решающую роль при выборе
методологии разработки ПО в проектах компании, так как разные заказчики
привыкли по-разному работать, кого устраивает водопадная методология,
кто-то же пропагандирует Scrum и гибкие методологии в целом. Также
проекты поддержки продуктов и те, которые активно разрабатывают новые
продукты, не могут преследовать одинаковые цели, соответственно им
необходимо использовать различные методологии разработки ПО.
Гибкие методологии в компанию ООО «Т-Системс РУС» пришли
относительно недавно. Основная масса разрабатываемых проектов является
довольно-таки
старыми,
поэтому
используется
обычная
водопадная
методология. Используется поставка нового функционала продукта в виде не
очень частых релизов, которые бывают в зависимости от проекта 1-3 раза в
полгода. Реализация продуктов происходит согласно спецификациям,
которые приходят на каждый релиз. Далее последовательно выполняются все
42

43.

этапы создания продукта. Процесс разработки в таких проектах является
довольно-таки формализованным и устоявшимся, что и подходит для
заказчиков проектов и их целей.
Новые проекты в компании зачастую начинаются «с нуля», либо с
самой ранней стадии разработки, поэтому с недавнего времени почти во всех
новых проектах компании используется Scrum как основная методология
разработки ПО.
Для сотрудников компании организованы внутренние курсы по Scrum,
которые проводятся опытными сотрудниками – специалистами в области
гибких методологий и Scrum, в частности. Данные курсы обязательны для
сотрудников, которые участвуют в новых проектах с применением Scrum.
Это благоприятно влияет на процессы разработки в проектных командах, так
как члены команды понимают все преимущества данной методологии, а
также знают, как правильно использовать методологию, чтобы получить
максимальную
полезную
эффективность
в
разработке
программных
продуктов.
Необходимо отметить, что Scrum активно поддерживается немецким
топ-менеджментом дочерней компании Deutsche Telekom AG, так что
инициатива использования Scrum спускается «сверху», что также является, в
данном случае, положительным фактором для Scrum в ООО «Т-Системс
РУС» - не нужно убеждать руководство в необходимости и целесообразности
Scrum, а, наоборот, он поддерживается руководством.
Описанные факторы в компании создают благоприятную среду для
использования и развития Scrum в новых проектах компании, но о переводе
на Scrum старых проектов пока не может идти речи, да и такая вероятность
мало реалистична в существующих реалиях производственных процессов.
43

44.

2.3.
Ключевые особенности разработки e-commerce приложений
Разработка e-commerce приложений включает в себя не только
разработку
интернет-магазинов,
но
и
также
любого
программного
обеспечения, связанного с торговлей в сети Интернет. Как и любая
разработка программных продуктов для различных отраслей хозяйства, она
отличается от разработки другого ПО, например, встроенных программ для
автомобилей
или
даже
от
схожих
веб-сайтов
для
управления
документооборотом.
Основной особенностью разработки систем электронной коммерции
является то, что они зачастую строятся на основе e-commerce платформы. По
этой причине разработка коренным образом отличается от обычной вебразработки, потому что приложение строится не просто на фреймворке или
библиотеке, а на платформе. C другой стороны, ни одна платформа
электронной коммерции не представляет собой уже готовый к запуску вебмагазин, который можно купить, настроить и запустить. То есть технически,
конечно, это возможно. Но ведь у каждого конкретного бизнеса уже есть
какие-то внутренние информационные системы и программное обеспечение,
устоявшиеся бизнес-процессы, ассортимент и принцип работы с ним,
накопленные данные, которые должны быть мигрированы. Все это требует
определенной доработки с точки зрения программирования и настройки под
особенности конкретного взятого бизнеса.
Любая платформа для разработки ПО имеет тысячи мест, которые
можно доработать программисту со своей бизнес и программной логикой,
можно переопределить или расширить стандартное поведение системы. На
практике
разработка
проектирование,
e-commerce
разработку и
приложения
представляет
тестирование множества
собой
модулей
по
отдельности или в составе программной платформы. У программиста есть
два различных варианта разработки продукта – переписать бизнес-логику
или использовать ту, что уже реализована в составе платформы. Все
44

45.

платформы основаны и созданы на известных и распространенных
инструментах программирования наподобие языков программирования Java
или PHP, что значительно упрощает подключение к проекту программистов
без практического опыта в конкретной e-сommerce платформе. В типичный
проект, разрабатывающийся на e-сommerce платформе, входят такие фазы,
как проектирование или изучение бизнес-процессов компании, настройка и
разработка логики обработки заказа, интеграция с платежными системами,
ERP и другими внешними системами. Но первая проблема, с которой
сталкиваются архитекторы и программисты, является задача правильного
выбора e-commerce платформы для разработки магазина.
Чтобы быть точно уверенным в соответствии проектируемой системы
структурным
блокам
и
функциональным
возможностям
e-commerce
платформы, нужно определить, с помощью каких конкретных модулей и
блоков этой программной платформы возможно реализовать тот или иной
необходимый
функционал,
нужно
также
оценить
объем
и
сроки
необходимых разработок или доработок, порядок внедрения.
E-commerce приложения – это веб-сайты, которые, как правило,
посещают тысячи или даже десятки, сотни тысяч пользователей каждый
день. Это требование отражается на разработке таких систем, так как нужно
предусмотреть
рост
количества
пользователей.
Также
необходимо
изначально выделять средства на необходимое оборудование (сервера, базы
данных и т.д.).
Зачастую разработчики в команде не имеют достаточно опыта в
конкретной e-commerce платформе. Поэтому отдать часть работы на
аутсорсинг
является
гораздо
более
рентабельным,
чем
обучение
разработчиков новой инфраструктуре развития электронной коммерции.
В Интернете работают тысячи опытных веб-разработчиков, многие из
которых имеют большой опыт работы с программными продуктами для
45

46.

разработки веб-сайтов электронной коммерции. Аутсорсинг часто является
экономически эффективной и разумной стратегией.
Важно помнить о том, что создание интернет-магазина это не только
работающий и запущенный код, но это также данные. В e-commerce системах
объём данных бывает огромным и перед тем, как начать функционировать,
данные для магазина должны быть заполнены. Обычно e-commerce
платформы предоставляют эффективные механизмы для управления такими
данными в виде отдельных веб-приложений в составе платформы.
Необходимо научить пользоваться данной системой сотрудников, которые
будут заполнять данные магазина, если платформа используется в компании
впервые. То есть отдавая продукт заказчику, нужно осуществлять обучение
сотрудников заказчика.
Независимо от того, насколько хороша продукция, продаваемая
посредством интернет-магазина или насколько совершенен сайт, многие из
клиентов будут сталкиваться с проблемами и им необходимо связаться со
службой поддержки. Из-за этого должна быть готовая техническая
поддержка, прежде чем веб-сайт даже запустится.
Клиенты будут сталкивать с вопросами от создания учетных записей и
удобства использования до проблем с выставлением счетов, которые никогда
не могли себе представить разработчики. Вот почему важно хорошее
обучение, а также отличные FAQ и документация.
В тестировании программного продукта e-commerce также существуют
свои особенности:
- большое количество сценариев тестирования, так как покупатель
может собрать информация о товаре, заказать, оплатить заказ и получить
различными способами, то есть количество вариантов заказа растёт в
геометрической прогрессии;
46

47.

- обычно в e-commerce приложениях используется интеграция с
другими системами оплаты, возможно, платёжными системами;
- современные e-commerce платформы имеют различные возможности
для купонов и акций, что в свою очередь требует тестирование бизнеслогики, а не функциональности.
Подытоживая, в разработке e-commerce приложения можно выделить
следующие этапы:
- анализ, необходимо тщательного изучить конкретные потребности
бизнеса, нужно проанализировать бизнес-требования, провести анализ
конкурентов, изучить технические возможности;
- дизайн, веб-дизайнеры прорабатывают все страницы сайта и
предоставляют их заказчику;
- реализация дизайна, нарисованные страницы преобразуется в гибкую
перекрестную технологию и совместимую с платформой HTML-оболочку в
зависимости от предлагаемой платформы электронной коммерции;
- программирование и создание базы данных, на этом этапе проекта
выполняется кодирование всех процессов и создаются инструменты
управления базой данных, все макеты меняются на настоящие динамические
страницы, управляемые базой данных;
- подключение систем оплаты, подключается одна из платёжных
систем, например, Secure Trading, Worldpay, Paypal и Paypal Pro, Sagepay,
Google Checkout, Authorize.Net и другие;
- системная интеграция, если есть требования, необходимо подключить
уже существующие ERP системы компании, например, Sage, Quickbooks,
SAP и Visual Manufacturing. POS-системы, данные системы предназначены
для решения различных задач, таких как управление запасами, выставление
47

48.

счетов, расчет заработной платы и даже для управления взаимоотношениями
с клиентами;
- проверка качества, прежде чем завершить продукт, необходимо
проверить
всю
функциональность
продукта,
юзабилити
сайта,
производительность и многое другое;
- импорт продуктов магазина, это возможно сделать вручную через
панель администратора платформы, либо автоматически путём импорта
какого-нибудь файла, определённого формата;
- развёртывание веб-сайте на сервере, регистрация доменного имени
сайта и прочие подобные работы;
- поисковая оптимизация, специалисты по SEO разрабатывают
специальные правила для продуктов, страниц сайта, чтобы можно было
активно конкурировать с другими интернет-магазинами в соответствующей
отрасли, также важно подключить Google Analytics, Яндекс Метрика и
другие системы анализа активности, для отслеживания пользовательской
активности на сайте;
- обучение, нужно обучить персонал, который будет заполнять каталог,
также
ознакомить
всех
сотрудников
с
администраторской
частью
программы, всеми функциями и настройками, это очень важно, так как
современные e-commerce платформы предоставляют просто огромное
количество различных функциональных возможностей и настроек, поэтому
сложно их изучить и пользоваться ими без предварительного обучения.
Все описанные особенности разработки e-commerce приложений нужно
учитывать при выборе методологии разработки.
48

49.

2.4.
Методологии разработки ПО для e-commerce приложений
IT-специалисты, веб-дизайнеры, инженеры, менеджеры и руководители
должны понимать, как применять концепции разработки программного
обеспечения для систем электронной коммерции и для лучшей интеграции
программного обеспечения с потребностями своего бизнеса. Специалистам в
IT сфере необходимо создать и применять методологию разработки, которая
решит все проблемы реализации e-commerce приложений. Те разработчики
программного
обеспечения,
которые
понимают
концепции
анализа,
архитектуры и дизайна, будут успешны в разработке систем e-commerce.
Важно понимать, что системы электронной коммерции - это новая и
уникальная форма разработки программного обеспечения. Они не должны
строиться
с
использованием
тех
же
самых
методологий,
которые
необходимы для построения любой информационной системы. Разработка
систем e-commerce зависит в первую очередь от детального анализа,
проектирования и реализации.
Разработчики программного обеспечения должны уметь понимать
потребности клиентов, обеспечивать требования к пользовательскому
интерфейсу, поддерживать безопасность системы, сетевую архитектуру,
обеспечивать интеграцию с системами, которые были до этого. Стандартные
методологии, как правило, основываются на существовании одинаковых
условий в бизнесе, но такого фактически не существует для систем
электронной торговли.
Для
систем
электронной
коммерции
IT-специалисты
должны
использовать жизненный цикл, который объединяет креативный дизайн,
рекламу, маркетинговые концепции (отличительные характеристики Web) и
требования к программной инженерии. Этот жизненный цикл может сочетать
традиционный жизненный цикл программного обеспечения (водопадная
модель разработки ПО) со спиральным жизненным циклом. При разработке с
использованием
спиральной
методологии
49
разрабатывается
каждый

50.

компонент независимого от общего продукта, каждый модуль должен иметь
свой собственный жизненный цикл, каждый компонент может быть
компонентом промежуточного ПО, объектами или повторно используемыми
приложениями. Традиционный подход (водопадная модель разработки ПО)
используется для анализа, проектирования или реализации. Таким образом,
для
разработки
e-commerce
приложений
лучше
всего
использовать
комбинацию водопадной модели разработки и спиральной и брать из них
лучшее.
Описанный выше подход использовался раньше и используется сейчас
для разработки крупных e-commerce приложений, но он не единственный
способ реализации таких продуктов. Гибкие методологии разработки ПО
(например, Scrum, экстремальное программирование и т. д.) стали очень
популярными
в
последние
годы
для
e-commerce
приложений.
Преимуществами гибкой разработки ПО обычно считаются повышенная
гибкость, более частая доставка бизнес функциональных возможностей,
расширение сотрудничества между деловыми и техническими группами и
способность справляться с часто меняющимися приоритетами и целями в
бизнесе.
Проекты по созданию e-commerce продуктов идеально подходят для
гибких методологий разработки ПО. Всё, как правило, движется немного
быстрее в электронной коммерции, чем в других областях. Приоритеты и
цели постоянно меняются, потому что нужно идти в ногу с конкуренцией и
тенденциями
клиентов,
а
также
чтобы
использовать
новейшие
технологические достижения, и чтобы получать богатый и бесценный опыт.
В e-commerce разработке нужно выпускать функциональность раньше и
чаще, а затем измерять (через веб-аналитику) эту функциональность, чтобы
понимать, что работает, а что нет, и итеративно усовершенствовать это. Как
правило, происходит близкое взаимодействие коммерческих и технических
сторон в электронной коммерции, то есть коммерческие предприятия в
50

51.

электронной коммерции довольно техничны, и не обязательно разработчику
ПО быть бухгалтером, менеджером по инвентаризации или другим
специалистом по бизнесу, чтобы понять, как веб-сайт повлияет на бизнес поэтому такое сотрудничество может быть очень эффективным.
Гибкие
и
итерационные
методологии
разработки
ПО
могут
использоваться в любом проекте, например, ERP-реализациях, операционных
системах и так далее, но они нигде так хорошо не подойдут, как для ecommerce разработки.
Рассмотренные
два
подхода
являются
основными
подходами
разработки ПО в e-commerce сфере, существуют и другие, но они очень мало
используются.
2.5.
Применение Scrum в проекте «Phoenix»
Проект «Phoenix» - один из новых e-commerce проектов, который
разрабатывается компанией ООО «Т-Системс РУС» с применением гибкой
методологии Scrum. Поэтому будут рассматриваться процессы разработки в
данном проекте, на основе результатов исследования и их анализа будет
сформирован ряд требований к новой методологии для e-commerce
разработки,
далее
будет
предпринята
попытка
применить
новую
методологию разработки программного обеспечения именно в этом проекте.
Цель проекта «Phoenix» заключается в разработке нового общего вебпортала
услуг
компании
Deutsche
Telekom,
новый
портал
будет
предоставлять пользователям доступ к телекоммуникационным услугам
компании Deutsche Telekom:
- подключение к мобильной сети Deutsche Telekom;
- управление пользовательским контрактом с изменением тарифа,
подключением новых опций;
51

52.

- покупка мобильных телефонов и аксессуаров, как с контрактом, так и
без;
- подключение стационарной связи, к сети Интернет;
- другие услуги компании Deutsche Telekom.
Пользовательский портал услуг, разрабатываемый проектом «Phoenix»
будет являться частью стратегии Deutsche Telekom «eChannel», который не
только объединит всю функциональность в одной системе, но и так же все
части системы будут иметь общую архитектуру и стэк технологий.
Новый продукт основан на платформе электронной коммерции Oracle
ATG Web Commerce, являющейся одним из лучших на рынке решений
уровня предприятия. На платформе основаны крупнейшие мировые
интернет-магазины, достоинства данной платформы описаны подробно в
предыдущей главе. Данные изменения позволят Deutsche Telekom повысить
качество обслуживания клиентов, как пользователей мобильной связи, так и
пользователей
стационарной,
что
позволит повысить
рентабельность
Deutsche Telekom на европейском рынке телекоммуникационных услуг.
Ранее было сказано, что ООО «Т-Системс РУС» использует Scrum для
новых проектов, проект «Phoenix» не стал исключением, в процессе
разработки используется классический Scrum с некоторыми особенностями,
присущими данному проекту.
Вся имплементация продукта делится на истории пользователя (user
story), это небольшие части функционала, обычно логически законченные, но
иногда большие задачи разбиваются на несколько user story. В проекте
существует практика – если одна история пользователя получается большой,
она делится на несколько маленьких, причём без смыслового разбиения.
Проект разрабатывается полностью не только в одной компании, но
также принимают участие в разработке польская аутсорс-компания. Она
52

53.

является экспертом в области e-commerce разработки и, в частности, имеет
огромный опыт разработки на платформе Oracle ATG Web Commerce.
Поэтому команда проекта является распределённой в разных компаниях и
странах, как это часто бывает в разработке коммерческого ПО.
2.5.1. Роли в проекте «Phoenix»
В проекте «Phoenix», как и в обычном процессе разработки в Scrum,
выделяют три основных роли: владелец продукта, скрам-мастер и команда.
Владелец продукта, в компании используется термин «product owner» –
это человек, отвечающий за приоритезацию требований, иногда за их
создание, а также за формальный приём историй пользователя на обзоре
спринта. В проекте «Phoenix» 3 владельца продукта, они взаимозаменяемы,
то есть, в целом проект знают весь, но лучше разбираются в отдельных
частях продукта, так как разрабатываемый продукт объединяет несколько
старых систем и функционал логически разделяемый.
Кроме владельца продукта в описании требований участвуют бизнесаналитики, называемые «дизайнерами пользовательских историй». Эти люди
прекрасно разбираются в отдельных и конкретных частях функционала
продукта, но в целом продукт могут и не знать. Они могут создавать
спецификации для историй пользователя. Также бизнес-аналитики не имеют
права «принимать» истории пользователей, хотя владельцы продуктов могут
привлекать их для участия в презентации user story.
В проекте имеется три команды разработки. Каждая команда состоит
из:
- скрам-мастера, он следит за выполнением историй пользователя
командой, ежедневно устраивает скрам-митинги и узнаёт текущий статус
команды, в начале спринта помогает проводить планирование спринта
53

54.

команде, в конце спринта организует демонстрацию всех выполненных
историй пользователя, проводит ретроспективу, также в обязанности скраммастера
входит
мониторинг
социальных
аспектов
команды,
административные и служебные вопросы и поддержание командного духа;
- 6-7 бэкенд-разработчиков, это Java разработчики, реализуют
серверную часть, используют и расширяют функционал платформы Oracle
ATG Web Commerce;
- 2 фронтенд разработчиков, используют JavaScript и CSS для вёрстки и
создания браузерной логики;
- 2 тестировщиков, они проверяют создаваемый функционал на
предмет соответствия требованиям, описанным в истории пользователя.
Команды имеют названия для удобства, названы разными цветами:
красный, синий, зелёный.
2.5.2. Артефакты Scrum в проекте
Основным артефактом Scrum является «беклог продукта» - это
упорядоченный по приоритету список всех задач, которые должны быть
сделаны в продукте. Его дополняют, изменяют, расставляют приоритеты
владельцы продукта и дизайнеры пользовательских историй. Беклог
продукта никогда не является полным и финальным. Начальная версия этого
документа содержала только первоначально известные требования, беклог
продукта постоянно меняется по мере обновления самого продукта.
Бэклог продукта содержит несколько типов задач:
- пользовательские истории;
- подзадачи для историй;
- дефекты (bugs);
54

55.

- улучшения (improvements);
- поставка (delivery) – задача выката стабильной версии продукта, либо
какого-то конкретного функционала или, например, базы данных.
Для
бэклога
продукта
в
проекте
«Phoenix»
используется
информационная система Atlassian JIRA, представленная на Рисунок 10 –
Бэклог продукта
Рисунок 10 – Бэклог продукта
Бэклог продукта описывает все задачи в целом продукта за всё время,
для записи задач конкретного спринта и команды используется Scrum-доска.
Это набор элементов бэклога продукта, выбранных для выполнения в
текущем спринте определённой командой. Пользовательские истории
попадают на Scrum-доску после планирования спринта команды.
Задачи на Scrum-доске очень детализированы, чтобы отследить
прогресс команды во время спринта, поэтому каждая пользовательская
история разбивается на подзадачи, которые можно выполнить одному члену
команды на один день. Так делается для того, чтобы можно было отследить
на ежедневном скрам-митинге, что сделал каждый член команды. А доске
55

56.

есть несколько стадий для каждой задачи. Первая «To do», что нужно
сделать, вторая «In progress» - задачи выполняются, также есть стадии для
задач, которые тестируются или проверяются и для выполненных задач.
Scrum-доска представлена на Рисунок 11.
Рисунок 11 – Scrum-доска команды
2.5.3. Процессы Scrum в проекте «Phoenix»
Scrum-митинг – это ежедневное собрание всех членов команды и
обсуждение текущего статуса каждого члена команды. Каждый отвечает на
вопросы: «Что сделал вчера?», «Что будет делать сегодня?», «Какие есть
проблемы?».
Данная встреча проводится в начале рабочего дня, около 11:00 и длится
не более 15 минут. Все становятся в круг, и начиная со скрам-мастера, все
члены команды выступают. Если команда распределённая и нет возможности
собраться лично, то устраиваются видеоконференции с показом scrum-доски.
Планирование спринта – это встреча всех членов команды с
владельцами продукта. Именно с этого момента начинается спринт.
56

57.

Проводится при личной встрече, редко по видеоконференции. Перед
планированием спринта все задачи в бэклоге должны быть в статусе готовом
к разработке, то есть нет открытых вопросов, всё детально описано, если
нужны прикреплены документы со спецификациями и скриншоты для
имплементируемого функционала.
Участвуют все члены команды, даже тестировщики. В проекте
«Phoenix» используется практика покер-планирования. Покер-планирование
(Planning poker) – это относительная оценка пользовательских историй
командой. Этот вид оценки не входит в классический Scrum, но является
одним из паттернов для оценки пользовательских историй.
Рисунок 12 – Карты для покер-планирования
Покер планирование происходит следующим образом:
- в начала планирования всем членам команды раздаются карты с
числами Фибоначчи от 0 до 21 (Рисунок 12 – Карты для покерпланирования), это стори-поинты;
- пользовательскую историю представляет владелец продукта;
57

58.

- команда задаёт уточняющие вопросы;
- происходит оценивание пользовательской истории, каждый член
команды показывают выбранную карту, если оценки отличаются друг от
друга, то происходит снова обсуждение и повторное голосование, пока не
будет одинаковая оценка у всех членов команды.
Оценка пользовательских историй происходит в условных оценках –
стори-поинтах. Оценка в «поинтах» – это сравнительная оценка, которая
показывает «размер» требований к истории пользователя относительно друг
друга. То есть важны относительные значения и не может быть некого
эталона. «Поинты» не имеют физических единиц измерения, ни временных,
ни каких-либо других.
Каждая команда имеет определённый объём стори-поинтов на спринт,
поэтому обсуждаются и оцениваются истории пользователя, пока общий
объём оценённых историй меньше объёма команды.
Обычно в проекте «Phoenix» планирование занимает около 3-4 часов и
проходит по понедельникам.
Следующим важным процессом является сам спринт. В проекте
«Phoenix» он длится 3 недели от понедельника, в который было
планирование, то есть 14 рабочих дней – продолжительность спринта.
В конце спринта проводится обзор спринта (используется термин
«демо») – показ владельцу продукта (и другим заинтересованным лицам,
например, дизайнерам пользовательских историй) работающего функционала
продукта, сделанного за спринт в рамках конкретной пользовательской
истории. Основная задача проведения обзора – приём пользовательских
историй владельцами продуктов и получение обратной связи.
Общий цикл спринта выглядит следующим образом (рисунок 13).
58

59.

Рисунок 13 – Обратная связь в проекте «Phoenix»
Презентация результатов работы помогает мотивировать команду, так
как есть возможность общения напрямую с заказчиком в лице владельца
продукта. На презентации участвуют абсолютно все члены команды,
включая тестировщиков и фронтенд-разработчиков.
В проекте принято, что показывает пользовательскую историю
разработчик, который больше всего в ней разбирается и её реализовывал. То
есть разные истории показывают разные люди. В результате получается, что
почти все разработчики участвуют в презентации. Если пользовательская
история не готова, то ответственный разработчик рассказывает и показывает,
что сделано. Далее на планировании уже следующего спринта остаток задач
по
пользовательской
истории
оценивается
в
стори-поинтах
и
она
заканчивается в следующем спринте.
После обзора спринта в команде происходит важная часть спринта –
ретроспектива. Ретроспективу проводят после обзора спринта спустя
небольшое количество времени (на следующий день), чтобы оперативно
59

60.

получить отзыв от каждого члена команды. Ретроспектива проводится в
каждой команде отдельно, важные для всего проекта выводы и результаты
сообщаются всем командам.
Вся команда собирается вместе со скрам-мастером для обсуждения
результатов спринта. Каждый член команды высказывается и отвечает на
вопросы:
- что понравилось в спринте?
- что не понравилось и как это исправить?
В проекте ретроспектива занимает по времени не более 30 минут.
2.6.
Недостатки в процессе разработки в проекте «Phoenix»
Ранее описывалось применение Scrum в проекте «Phoenix», и как уже
ранее говорилось: Scrum хорошо подходит для разработки e-commerce
приложений, однако во время разработки в проекте можно найти следующие
недостатки.
Существует сложность оценки пользовательских историй, связанных с
функционалом e-commerce платформы. Разработчики без должного опыта
или даже с ним не могут точно оценить сложность задачи, так как до конца
непонятно, что можно использовать «из коробки» e-commerce платформы, а
что придётся реализовывать самим или что нужно расширять. Поэтому
зачастую разработчики, а, значит, команда в целом ошибается с оценкой.
Из предыдущей проблемы вытекает ещё одна. Имея рассчитанный
объём
стори-поинтов
на
спринт,
команда
может
набрать
больше
пользовательских историй, чем может выполнить, либо, наоборот, взять
меньше и потом работать до конца спринта без активных задач, хотя можно
использовать рациональнее это время.
60

61.

При использовании методологии Scrum не учитываются особенности ecommerce разработки, а именно то, что большого объёма работы требует
заполнение контента интернет-магазина, зачастую невозможно показать
владельцу продукта пользовательскую историю без контента.
Также существуют проблемы, не относящиеся к методологии, а к её
использованию:
- большой размер команды, из-за этого хуже становится коммуникация
между членами команды;
- малая продолжительность спринта, из-за этого нет возможности
команде разрабатывать большие пользовательские истории.
Рассмотрев
специфику
разработки
e-commerce
приложений
и
проанализировав процесс разработки в проекте «Phoenix», а также выявив в
нём недостатки, можно приступать к созданию новой рациональной и
применимой Agile-методологии.
61

62.

3. Разработка Agile методологии разработки ПО
В главе составляются требования к разрабатываемой методологии,
формируется ряд улучшений и нововведений, на основе который создаётся и
описывается методология разработки ПО.
3.1.
Определение требований к новой методологии
Проанализировав процесс разработки e-commerce продукта в проекте
«Phoenix» в предыдущей главе, был определён ряд недостатков в применении
Scrum для e-commerce приложений. Главное из них – это то, что не
учитываются в Scrum особенности e-commerce разработки, поэтому
требования к разрабатываемой методологии будут основаны на этом, очень
важном моменте.
Список требований к методологии:
1. Применимость к разработке e-commerce приложений. Необходимо
ориентироваться на разработку функционала интернет-магазина.
2. Максимально
оптимальное
использование
всех
человеческих
ресурсов (разработчиков, дизайнеров, редакторов, тестировщиков).
3. Повышение скорости работ всех команд и проекта в целом без
потерь качества продукта.
4. Способность
инкременты
производить
полностью
продукта,
готовая
качества
продукта,
готовые
для
функциональность
показа
интернет-
магазина.
5. Повышение
также
за
счёт
средств
автоматизации.
6. Возможность более глубокого анализа и оценки своей работы для
команды в целом.
7. Быстрый переход от Scrum без лишних ресурсных и временных
издержек в реализации продукта.
62

63.

8. Применимость методологии для других e-commerce проектов,
довольно-таки долгих и больших.
9. Способность применять методологию разработки ПО «из коробки».
Для удовлетворения всех данных потребностей будут осуществляться
нововведения. Они будут касаться, как структуры команды, так и процессов
разработки.
3.2.
Изменение и нововведения в проекте
Ранее был сформирован список требований к методологии и
улучшений, которые нужно сделать в процессе разработки в проекте
«Phoenix».
3.2.1. Структурные изменения в команде
Прежде всего, нужно начать со структурных изменений в команде
разработки.
Рисунок 14 – Старая структура проекта «Phoenix»
63

64.

Как уже отмечалось ранее, проект «Phoenix» делится на три команды,
структура представлена на Ошибка! Источник ссылки не найден.Но
данная структура не идеально, как говорилось, команды слишком большие и
коммуникация в команде затрудняется, поэтому предлагается следующая
структура.
Рисунок 14 - Новая структура проекта «Phoenix»
Как видно на рисунке, размеры существующих команд разработки
стали меньше. Всего в командах было 3 скрам-мастера, 6 тестировщиков, 6
фронтенд-разработчиков, 20 бекенд-разработчиков.
Эти же люди были
распределены в новые команды.
Теперь размер команды разработки фиксирован и составляет:
- 1 скрам-мастер;
- 1 фронтенд-разработчик;
- 4 бекенд-разработчика;
64

65.

- 1 тестировщик.
Так как человеческие ресурсы были освобождены, была создана новая
команда разработки – команда «Yellow», такая же по составу, как и другие
три команды.
Кроме того, была создана новая объединённая команда на основе
свободных тестировщиков и разработчиков для автоматизированного
тестирования
продукта,
это
позволит
гораздо
повысить
качество
создаваемого продукта.
Одним из требований к методологии было – переход без лишних
человеческих ресурсов, при данных изменения оно выполняется.
Процесс разработки и взаимодействие команд будет описано далее.
3.2.2. Изменения в процессе разработки
Одной из самых больших проблем в процессе разработки в проекте
«Phoenix» является ошибочная оценка пользовательских историй во время
планирования спринта из-за применимости e-commerce платформ, так как
заранее неизвестно, какой функционал придётся реализовывать, а какой нет.
Поэтому первым нововведением будет предварительное разделение
пользовательских историй между командами за 3 дня до планирования
спринта, чтобы команда могла рассмотреть, обсудить пользовательские
истории и уже на планировании более детально задавать вопросы владельцу
продукта,
также
это
поможет
команде
правильно
оценивать
пользовательскую историю. Предлагается дополнительное обсуждение за три
дня до планирования, в котором будут участвовать владельцы продукта и все
скрам-мастера, на нём будет проводится предварительное разделение
пользовательских историй между командами. Данное обсуждение будет
называться refinement meeting. На планировании команда не обязана взять
65

66.

все пользовательские истории, которые распределены на неё, основным
критерием отбора будет оставаться командная скорость и объём сторипоинтов, который может взять на себя команда.
Для правильной оценки пользовательских историй также предлагается
введение обязательного технического обзора всех пользовательских историй
одним из разработчиков-экспертов в данной e-commerce платформе.
Обязательным условием будет то, что пользовательская история будет
допущена на разделение на refinement митинге только при наличии
технического обзора и предварительной оценки.
Также по-новому будет высчитываться скорость команды и объём
стори-поинтов, которые команда может взять в следующем спринте. Для
этого
будет
введена
дополнительная
оценка
уже
реализованных
пользовательских историй на ретроспективе. То есть в конце спринта
команда заново оценивает уже сделанные пользовательские истории. В
хорошем случае оценка должна совпадать с той оценкой, которая была
поставлена на планировании, но может и отличаться, причём, как в большую,
так и меньшую стороны.
Суммарная оценка всех реализованных пользовательских историй на
ретроспективе будет являться объёмом на следующий спринт, от этого числа
будет отталкиваться команда на следующем планировании. Необходимо
также умножать данное значение на коэффициент загруженности команды,
который учитывает государственные праздники, отпуска, отгулы, болезни и
т. д. Также данный коэффициент нужно рассчитывать скрам-мастеру для
следующего планирования, учитывая запланированные отсутствия членов
команды.
На
Рисунок
15
–
Расчёт
объёма
команды
на
следующий
спринтизображен описанный алгоритм для двух спринтов, чтобы было
проще понять данный процесс. Нужно помнить, что для определения объёма
66

67.

следующего спринта, необходимы два коэффициента загруженности: для
прошлого спринта и будущего.
Рисунок 15 – Расчёт объёма команды на следующий спринт
Данное нововведение позволяет рационально использовать ресурсы
команды.
Ранее
было
сказано,
что
будет
создана
новая
команда
автоматизированного тестирования и команда редакторов. Это было сделано
для разделения процесса разработки каждой пользовательской истории на
несколько этапов.
Первый этап: спринт разработки (2 недели), одна из команд разработки
берёт историю, оценивает её, разрабатывает. Происходит контроль качества
на соответствие требованиям пользовательской истории. В конце спринта
презентация владельцу продукта не происходит.
Второй этап: следующие 2 недели, команда редакторов заполняет всем
необходимым
контентом
сайт,
а
также
создаёт
документация для дальнейшего заполнения сайта.
67
пользовательскую

68.

Третий этап: 2 недели, команда автоматизированного тестирования
создаёт автотесты для всего функционала, созданного в данном спринте
всеми командами, если находятся дефекты, команда разработки, которая
реализовывала
пользовательскую
историю,
устраняет
их.
В
конце
происходит презентация пользовательской истории владельцу продукта на
обзоре спринта.
Рисунок 17 – Процесс разработки одной пользовательской истории
Такой подход решает сразу несколько задач и соответствует
требованиям к разрабатываемой методологии разработки ПО:
- повышает качество продукта, так как продукт проверяется дважды –
во время спринта разработки разработчиком и тестировщиком, далее при
помощи автотестирования;
- поставляется полностью законченный инкремент продукта владельцу
продукта, так можно лучше оценить функционал с уже заполненным
контентом.
68

69.

3.3.
Описание новой методологии
Разработанная методология ПО подходит для проектов при следующих
условиях:
- проект для разработки e-commerce приложения;
- разрабатываемый продукт базируется на e-commerce платформе;
- проект немаленький по временным рамкам;
- в проекте больше 25 человек.
Далее будет описана непосредственно сама методология разработки
ПО, но так как она основана на Scrum, некоторые моменты из Scrum не будут
объясняться.
Разработанную методологию можно описать по трём составляющим:
роли, артефакты, процессы.
Роли:
1. Владелец продукта, также могут быть бизнес-аналитики.
2. Скрам-мастер в каждой команде.
3. Весь проект делится на небольшие команды. Оптимальный размер
команды – 7 человек. Команды бывают нескольких типов:
- команда разработки (1 скрам-мастер, 1 фронтенд-разработчик, 4
бэкенд-разработчика, 1 тестировщик);
- команда редакторов (1 скрам-мастер и редакторы);
- команда автоматизированного тестирования (1 скрам-мастер и
команда автотестировщиков).
Артефакты:
1. Беклог продукта. Так же, как и в Scrum, но у пользовательских
историй вводится несколько дополнительных состояний:
69

70.

-
в
анализе
(когда
пользовательская
история
описывается
владельцем продукта или бизнес-аналитиком);
- анализ завершён;
- готова для разработки (после технического обзора экспертов в ecommerce платформе);
- разработка в прогрессе;
- разработка завершена;
- наполнение контента в прогрессе;
- наполнение контента завершено;
- в автотестировании;
- автотестирование завершено.
2. Беклог спринта или скрам доска.
3. Инкремент продукта, полностью готовый функционал спустя 6
недель.
Процессы:
1. Технический
обзор
и
предварительная
оценка.
Опытный
программист, эксперт в e-commerce платформе, делает обзор и
предварительно оценивает пользовательскую историю, чтобы затем
было проще оценивать команде.
2. Распределение историй пользователя. Участвуют все скрам-мастера
и
владельцы
продуктов,
происходит
распределение
пользовательских историй между командами разработки за 3 дня до
планирования, чтобы команды разработки успели ознакомиться.
3. Планирование спринта. Оцениваются пользовательские истории в
по системе покер-планирование на основе экспертной оценки.
Происходит в каждой команде разработки отдельно и проводится
только в командах разработки.
4. Передача пользовательской истории команде редакторов.
5. Передача пользовательской истории команде автотестирования.
70

71.

6. Обзор спринта. Команда разработки представляет пользовательскую
историю, полностью готовую через 6 недель после планирования.
7. Ретроспектива. Происходит конечная оценка «по факту» для лучшей
дальнейшей оценки.
На Рисунок 16 – Общая схема новой методологииизображён весь
процесс разработки.
Рисунок 16 – Общая схема новой методологии
Данная
методология
позволяет
поставлять
конечный,
протестированный инкремент продукта с автотестами через 6 недель после
планирования, но зато каждые 2 недели.
Спроектированная методология будет внедрятся в реальный проект,
разрабатывающий e-commerce продукт.
71

72.

4. Внедрение новой методологии
В данной главе описывается применение разработанной методологии в
реальном проекте
4.1.
Внедрение методологии в проекте «Phoenix»
Внедрение методологии состояло из трёх важных этапов: одобрение
руководством, структурные изменения, изменения в процессах разработки.
Все изменения в командах обсуждались с руководством подразделения
– программными менеджерами. Поэтому первым этапом стала презентация
новой методологии руководству и всем заинтересованным лицам.
Дале было получено одобрение от руководства и поддержка по всем
возникающим вопросам и проблемам.
4.1.1. Внедрение структурных изменений
Необходимо начинать со структурных изменений в проекте, а потом
перейти к нововведениям в процессах разработки.
Необходимо было создать четвертую команду разработки из трёх
существующих, а также команду автоматизированного тестирования. До
этого были три команды со скрам мастерами, 2 фронт-енд разработчиками, 67 бекенд-разработчиками и 2 тестировщиками. Для этого были проведены
следующие изменения:
1. Так как автотестировщиков не было до этого в команде,
предполагалось, что некоторые тестировщики и разработчики
перейдут по желанию в автоматизированное тестирование. Из 6
тестировщиков 2 ушли в новую команду тестирования, и осталось
по одному тестировщику в командах разработки.
72

73.

2. Для создания фреймворка автоматизированного тестирования новой
команде нужны бекенд разработчики. Всего 20 разработчиков, 16
остаются в командах разработки, по 4 в каждой, остальные 4
перешли в команду тестирования.
3. Также предполагается автоматизированное тестирование фронтенда.
Это специальные тесты на JavaScript, поэтому 2 из 6 фронтенд
разработчиков ушли в новую команду, остальные – по одному в
команде.
4. Ранее было 3 скрам-мастера, по одному в каждой команде. Чтобы не
набирать новых людей, каждый скрам-мастер будет выполнять свою
функцию в двух командах.
4.1.2. Внедрение изменений в процессах разработки
Изменения в процессах было легче реализовать. Всем членам всех
команд были объявлены новые «правила игры».
Сначала для пользовательских историй были проведены технические
обзоры и оценка экспертами. Далее на распределении за 3 дня до
планирования пользовательские истории из беклога распределяются между
командами разработки, чтобы команды могли ознакомиться с ними. Затем
состоялось планирование первого спринта для команд разработки.
Спустя 2 недели пользовательские истории были переданы команде
редакторов.
Демонстрации
ретроспективы.
владельцу
Состоялось
продукта
планирование
2-го
не
было,
спринта
для
как
и
команд
разработки.
Спустя ещё 2 недели, команда редакторов передала пользовательские
истории
1-го
спринта
команде
тестирования,
в
свою
очередь,
пользовательские истории 2-го спринта были переданы команде редакторов.
73

74.

Демонстрации и ретроспективы также не было. Состоялось планирование 3го спринта для команд разработки.
Через 2 недели, то есть спустя 6 недель после внедрения состоялась
первая демонстрация инкремента продукта владельцу продукта, с уже
заполненным контентом и наличием автотестов, что делает продукт на
порядок качественнее.
4.2.
Оценка экономической и временной выгоды использования
методологии
Методология
разработки
внедрена, но, чтобы
оценить её
по
достоинству, необходимо сравнить статистические данные об объёмах
разработки до внедрения и после. Так как структурные изменения в проекте
и нововведения в процессах разработки не повлекли за собой финансовые
потери, так как количество человек в проекте осталось неизменным. Все
данные представлены в стори-поинтах – основной оценке в процессе Scrum.
Из статистических данных были взяты данные за последние 4 спринта
до проведения реформ и данные за 6 последних полноценных спринтов (с
показом владельцу продукта, первых 2 спринта не считались) после реформ.
4 спринта до и 6 спринтов после– это 12 рабочих недель.
Таблица 2 – Статистические данные спринтов до реформ
Планировалось
Выполнено
%
Спринт 8
135
120
89
Спринт 9
145
95
66
Спринт 10
142
102
72
Спринт 11
150
114
76
В сумме
572
431
75
74

75.

Таблица 3 – Данные спринтов после преобразований
Планировалось
Выполнено
%
Спринт 14
125
99
79
Спринт 15
110
95
86
Спринт 16
101
96
95
Спринт 17
97
92
95
Спринт 18
99
97
98
Спринт 19
96
89
93
В сумме
628
568
90
В таблицах 2-3 представлены данные за 12 недель разработки до
перехода на новую методологию разработки ПО и после. Из неё можно
сделать 2 вывода:
1. Скорость проекта. До составляла 431 стори-поинт, после – 568, то
есть выполнено объёма работы на 32% больше, чем до применения
новой методологии.
2. Качество оценки команды. Раньше было 75%, стало – 90%, команда
стала делать оценки пользовательских историй и правильнее
оценивать свои силы на 20%.
В результате перехода на новую методологию разработки ПО команда
проекта в целом стала быстрее выполнять свои задачи и правильнее
оценивать свои силы, то есть стало легче прогнозировать работу проекта.
Также стало лучше качество продукта за счёт автоматизированного
тестирования.
4.3.
Сравнение разработанной методологии со Scrum
Разработанная методология основана на Scrum, но в отличие от
классического Scrum имеет ряд особенностей и нововведений. Данные
75

76.

нововведения особенно применимы для e-commerce разработки и для
больших проектов.
Разработанная методология имеет ряд сходств, как со Scrum, так и с
инкрементной методологией разработки ПО.
Все отличия приведены в Таблица 4 – Отличия Scrum и разработанной
методологии
Таблица 4 – Отличия Scrum и разработанной методологии
Разработанная
методология
2 недели
3 спринта
Scrum
Длина спринта
Длина
цикла
производства
инкремента продукта
Поставка инкремента
Оценка
пользовательских
историй
1-4 недели
1 спринт
Поставляется
Работающий инкремент
продукта,
который
нужно дополнять для
того, чтобы его можно
было
«выкатывать»
пользователям
1 раз во время спринта
2 раза: во время спринта
и автотестирование
Все работают по одним и Команды
разработки
тем же процессам
работают по гибким
принципам,
другие
команды – по-другому
Тестирование
Особенности
Каждый спринт
1 раз на планирование
4.4.
Каждый спринт
3 раза, первый раз во
время
технического
обзора, второй – на
планировании спринта,
третий
–
на
ретроспективе
Полностью
готовый
инкремент
продукта,
готовый
для
пользователей
Преимущества и недостатки
При применении описанной методологии разработки ПО можно
выделить следующие преимущества:
76

77.

- хорошо применима для проектов e-commerce;
- повышает скорость работы команды;
-
повышает
уровень
и
качество
продукта,
благодаря
автоматизированному тестированию;
- ориентирована на анализ команды проекта своей работы;
- позволяет делать частые поставки инкремента продукта.
К недостаткам стоит отнести:
- применимость только в больших проектах, разделённых на команды;
- необходимость поиска специалистов для автоматизированного
тестирования;
- оптимальная применимость в e-commerce проектах.
77

78.

5. Составление бизнес-плана по коммерциализации результатов НИР
магистранта
5.1.
Концепция технико-экономического обоснования разработки
проекта
Технико-экономическое обоснование – это изучение экономической
выгодности, анализ и расчет экономических показателей создаваемого
инвестиционного проекта. Главной задачей при составлении ТЭО является
оценка затрат на инвестиционный проект и его результатов. В данном
разделе будет проведено ТЭО для анализа и проектирования новой
методологии разработки ПО, что является областью знаний в IT. Так как
проектирование и создание методологии является коммерческим заказом для
компании ООО «Т-Системс РУС», очень важно знать бюджет, который
необходимо выделить для этого.
Целью работы является создание оптимальной методологии разработки
ПО на основе Scrum для реализации e-commerce приложений.
Законченная
работа
представляет
собой
описание методологии
разработки ПО, в котором присутствуют все правила и подходы для
разработки
ПО,
также
присутствуют
рекомендации
для
внедрения
разработанной методологии в проекты.
Спроектированная методология разработки ПО будет внедрятся во все
проекты, которые занимаются созданием e-commerce приложений в
компании ООО «Т-Системс РУС». Если разработка окажется успешной,
возможно, данная методология будет продаваться другим компаниям.
78

79.

5.2.
Трудоемкость и календарный план выполнения работы
Расчет полных затрат при выполнении ВКР начинается с составления
детализированного плана работ, которые необходимо выполнить, чтобы
решить поставленную задачу. Основой для разработки детализированного
плана является календарный план работы.
Для расчета затрат на этапе проектирования необходимо определить
продолжительность
каждой
работы.
Существует
несколько
способов
определения продолжительности работ, однако, в данном случае наиболее
удобно использовать определение продолжительности по факту, то есть
учитывать время, фактически затраченное исполнителями на выполнение
каждого этапа работы. От продолжительности работ зависит трудоемкость.
Для каждого исполнителя необходимо также определить ставку
заработной платы за день. Для определения дневной ставки заработной
платы необходимо разделить заработную плату (оклад) за месяц на
количество рабочих дней в месяце.
Для этого необходимо знать заработную плату исполнителей. Научный
руководитель работает доцентом на кафедре и является кандидатом
технических наук, поэтому его заработная плата составляет 25000 руб./мес.
А, соответственно, заработная плата в день будет равна 25000/21=1190
руб./день. Исполнитель работает инженером-программистом, поэтому его
зарплата как для инженерно-технического работника вне подразделений,
составляет 10000 руб./мес. и заработная плата в день составляет
10000/21=476 руб./день.
Выполнение работы длилось 17 недель, так как в неделе 5 рабочих
дней, то всего было потрачено 16*5=85 рабочих дней.
Наиболее удобно представить информацию о трудоемкости работ в
виде таблицы 5.
79

80.

Таблица 5 – Трудоёмкость этапов разработки
Трудоемкость,
дней
№ Наименование работы
человеко-
Исполнитель Руководитель
1
Постановка задачи, ее описание
2
2
2
Рассмотрение предметной области – ecommerce
разработки
и
Agile
методологий
10
2
3
Анализ текущего состояния процессов
разработки ПО в ООО «Т-Системс РУС»
18
2
4
Разработка новой Agile методологии
разработки ПО
15
1
5
Внедрение
спроектированной
методологии в проекты
24
2
6
Оформление пояснительной записки
10
-
7
Оформление презентации
3
1
8
Подготовка к защите и предзащита
3
2
85
12
Итого:
На основе данных о трудоемкости выполняемых работ и ставке за день
определяются затраты на заработную плату.
5.3.
Смета затрат на выполнение разработки проекта
Основная заработная плата.
Основная заработная плата вычисляется по формуле
80

81.

k
Зосн. з / пл Ti Ci
i 1
(1)
где Зосн.з/пл – расходы на основную заработную плату исполнителей
(руб.);
k – количество исполнителей;