22
Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную
книгу, в которой детально изложил концепцию RAD и возможности её
применения. В настоящее время RAD становится общепринятой схемой для
создания средств разработки программных продуктов [16].
Основными принципами RAD являются:
Инструментарий должен быть нацелен на минимизацию времени
разработки;
Активное взаимодействие с заказчикоМ.: новая версия продукта
основывается на оценке результата предыдущей версии
заказчиком;
Минимизация времени разработки, за счёт переноса готовых
решений в новую версию;
Команда разработчиков должна тесно сотрудничать, каждый
участник должен выполнять несколько обязанностей;
Управление проектом должно минимизировать длительность
цикла разработки;
RAD предполагает, что разработка ПО осуществляется небольшой
командой разработчиков от 2 до 10 специалистов с широким спектром
компетенций за срок порядка трёх-четырёх месяцев с использование
инкрементного прототипирования и применением средств визуального
моделирования и разработки [16].
RAD предполагает использование целого комплекса инструментов
помимо языка быстрой разработки: системы сбора требований, среды
разработки, фреймворков, программы для группового общения, ПО для
тестирования. Одним из примеров такого инструментария, ориентированного
на RAD, можно назвать CodeGear RAD Studio, изначально выпущенную
компанией Borland в дочерней компании CodeGear на базе Borland Developer
Studio и вышедшую в свет в 2007.
23
Основными преимуществами RAD считаются:
высокая скорость разработки;
низкая стоимость;
высокое качество;
К недостаткам RAD рад следует отнести:
Необходимость участия заказчика в проекте на всех этапах
разработки;
Необходимость выполнения разработки командой
высококвалифицированных разработчиков, готовых к
совмещению нескольких ролей;
Необходимость наличия компонент, пригодных для повторного
использования компоненты;
Жесткие временные ограничения;
Риск утраты контроля над сроками проекта;
Требования к высокой квалификации разработчиков и риски при
управлении сроками проекта следует считать важной причиной утраты
популярности RAD методологии. Так же следует отметить, что RAD не
гарантирует высокого качества решения, жертвуя им ради цены и скорости,
что крайне нежелательно при разработке платформенных решений,
призванных в дальнейшем стать основой для долгоживущих продуктов[6].
От утрачивающих популярность методологий перейдем к наиболее
распространенным сегодня Scrum и Kanban. Обе эти методологии
методологии относятся к группе гибких методологий Agile.
В настоящее время, Scrum является одной из наиболее популярных
методологий разработки ПО. Согласно определению, Scrum — набор
принципов, ценностей, политик и артефактов, на которых строится процесс
SCRUM-разработки [12]. При применении Scrum подхода весь процесс
24
разработки делится на ограниченные во времени, обычно около 2х недель,
реже от 1 до 4х недель, итерации – спринты, в период которых создается
приращение функционала продукта. Разработка обычно ведется командой из
5-9 человек, в которую могут входить специалисты различного профиля. При
этом в команде отсутствует выделенная роль руководителя, вместо этого в
команде выделяется Scrum master, задачей которого является обеспечение
правильного выполнения Scrum процесса, помощь команде, защита ее от
внешних воздействий. Ключевой задачей этой роли является построению
эффективной самоорганизующейся команды.
В целом, процесс развития продукта при использовании Scrum
методологий можно представлен на Рисунке 4.
Рисунок 4. Разработки с использованием Scrum методологий.
Источник: URL https://www.mindsparktechnologies.com/agile-
approach-software-development/
Основным инструментом учета требований при использовании Scrum
методологии является Список пожеланий проекта (Project backlog),
содержащий требования к функциональности продукта, упорядоченные по
степени их важности. Project backlog открыт для редактирования.
25
Из Project backlog производится отбор задач, которые должны быть
решены в период каждого следующего спринта. Эти задачи включаются
список задач спринта (Sprint backlog). Для каждого из спринтов определяются
его бизнес-цели [12].
Для отслеживания прогресса как всего проекта, так и каждого из
спринтов используются диаграммы сгорания задач. Такие диаграммы
обновляются ежедневно, что позволяет в реальном режиме времени
фиксировать процесс продвижения к цели проекта, выявлять проблемы и
своевременно реагировать.
Для управления жизненным циклом задач используется специальный
инструмент Доска задач – чаще всего виртуальная создаваемая при помощи
специального ПО, предназначенных управления процессом разработки.
На такой доске располагаются карточки задач. Доска делится на
вертикальные колонки, соответствующие жизненному циклу задач от
«Включена в спринт» или «Сделать» через все стадии рабочего процесса над
задачей до состояния «Завершена» или «Выполнена». Состав колонок доски
может меняться в различных командах в зависимости от формально
обозначаемых этапов жизненного цикла задачи. Основным назначением такой
доски является непрерывное отслеживание состояние задач спринта. Стоит
отметить, что некоторые команды помимо электронной доски предпочитают
использовать реальные настенные доски для более наглядной визуализации
задач. На такие доски клеятся клейкие бумажные стикеры, которые
перемещаются слева направо по мере выполнения задач.
Помимо указанных выше инструментов управления процессом
разработкой, Scrum включает в себя ряд практик для более эффективного
управления процессом разработки, такие как оценка сроков выполнения задач
при помощи Покер планирования (Poker planning), ежедневные короткие
26
встречи для обсуждения того что было сделано, того что предстоит сделать, и
предполагаемых проблем (Standup) и тд.
Важными преимуществами Scrum являются:
Система пошагового продвижения сокращает время выхода на
рынок;
Обеспечивает ежедневный контроль над ходом работ;
Гибкость, возможность значительно менять состав работ при
необходимости;
К недостаткам Scrum следует отнести:
Зачастую низкая степень документирования (см. принципы Agile);
Необходимость полагаться на самоорганизацию команды;
Трудности при планировании и структурировании проекта
Kanban как и Scrum является гибкой методологией, опирающейся на
реализующей принципы манифеста Agile. Kanban берет свое начало в система
организации производства и снабжения, созданной компанией Toyota. Эти
принципы были изложены в книге Тайити Оно «Производственная система
Тойоты» [7]. Главный из принципов такой производственной системы можно
определить как «точно в срок». Kanban, в отличии от Scrum предполагает
вытягивающую методологию, при которой новая задача порождается
необходимость своевременно предоставить материал для решения следующей
задачи.
Kanban так же как и Scrum предполагает работу команды разработчиков
в режиме самоорганизации. Как и в Scrum, в Kanban используют Доску задач
для планирования и отслеживания работы, как и в Scrum, разработка в Kanban
производится в рамках спринтов, однако в отличии от Scrum:
В Kanban задачи могут добавляться на доску в произвольный
момент времени по мере необходимости;
27
В команде Kanban обычно отсутствуют выделенные роли, в том
числе Scrum master;
В Kanban в первую очередь предполагается ориентацией на
задачи, а не на спринты;
В Kanban не предполагает четкого планирования сроков на
выполнения конкретной задачи или спринта;
Kanban обычно оперируют меньшим количеством более крупных
задач;
К преимуществам Kanban следует отнести:
Высокую гибкость;
Хорошую пригодность для работы в проектах, не имеющих
четкого плана, но активно работающих над разработкой, например
в стартапах;
Недостатками Kanban является:
Методология плохо работает с большими командами (больше 5
человек);
Значительно более высокие чем в Scrum требования к
самоорганизации команды;
В чистом виде, Kanban плохо работает с кросс-функциональными
командами;
Kanban плохо подходит для долгосрочного планирования;
Таким образом, на основании проведенного обзора современных
методологий управления процессом разработки ПО, мы можем сделать вывод,
что в настоящий момент наибольшее распространение получают гибкие
методологии разработки, такие как Scrum и Kanban, однако такие
28
методологии, как RAD и XP все еще не утратили свою актуальность и
используются рядом компаний.
Выводы по главе 1
В Главе 1 мы провели исследование вопросов, связанных с
деятельностью проектных организаций, занимающихся разработкой
программного обеспечения, таких как выбор оптимальной организационный
структуры в проектной организации и выбор методологии управления
процессом разработки ПО. Результаты данного исследования позволят нам
выбрать оптимальную структуру и методологию управления для создаваемого
в компании Акселот подразделения, а так же помогут в дальнейшем
оптимизировать структуру Департамента развития компании Акселот.
29
Глава 2. Анализ деятельности и продуктов компании
«Акселот»
2.1 История развития и организационно-экономическая
характеристика компании «Акселот»
Компания Акселот возникла в 1998 году, как небольшой бизнес по
дистрибьюции продуктов 1С. Так же компания занималась заказными
разработки на платформе 1С и доработкой стандартных конфигураций 1С. Как
и многие другие компании, Акселот стремился перейти от фазы дистрибьюции
чужих продуктов к созданию собственной продуктовой линейки, основным
приоритетом компании на тот момент стало создание информационный
систем для автоматизации деятельности предприятия. Так как спектр
направлений деятельности, автоматизируемых информационными системами
на платформе 1С крайне велик, а залог успеха компании кроется в первую
очередь в глубоком понимании предметной области и бизнес процессов
автоматизируемой деятельности, для достижения успеха компании
необходимо было выбрать свое направление развития. К 2003 году компания
Акселот компания уже имела достаточный имела опыт автоматизации
различных производственных процессов и достаточно хорошо представляла
рынок 1С систем, чтобы выбрать преимущественное направление
деятельности. В 2003 году компания курс на разработку и внедрение
автоматизированных систем управления логистикой 1С (Источник: Интервью
в вице-президентом компании Акскелот Власовым М. Г)
При всей перспективности выбранного направления компания
изначально шла на определенный риск, причиной которого было фактическое
отсутствие на рынке труда специалистов по логистике. Первые логисты-
профессионалы вышли из российских ВУЗов только в 2004; связанную с
логистикой отечественную научную базу на тот момент можно было назвать
довольно слабой. В Акселот решили самостоятельно растить кадры для
автоматизации логистики из опытных консультантов и программистов
30
компании. Основным источником профильных знаний стал западный опыт,
почерпнутый из специализированных изданий. Тщательно исследовались все
доступные литературные источники по теме, отыскивались и
переводились лучшие профессиональные издания. В итоге компания успешно
справилась с поставленной перед собой задачей. Более того, одним из видов
деятельности компании стал перевод и выпуск на русском языке
профессиональной литературы в области логистики.
В последующие годы были созданы и выпущены на рынок следующие
продукты:
2004 — Создана «1С-Логистика: Управление складом»
2005 — Создана «1С-Логистика: Управление складом 2»
2007 — Создана «1С-Логистика: Управление перевозками»
2008 — Создана «1С-Логистика: Управление складом 3»
2012 — Создана «1С:Предприятие 8. WMS Логистика. Управление складом»
2015 — Создана «AXELOT: TMS Управление транспортом и перевозками»
2015 — Создана «AXELOT: TMS Управление транспортом и перевозками»
2017 — Создана «AXELOT: WMS X5» Управление складом (Источник:
История компании Акселот. URL: https://www.axelot.ru/why/history/)
Так же в 2012 компания разработала и выпустила на рынок собственное
решение «Сервисная шина предприятия» (ESB), а в 2015 собственную систему
«Управления основными данными» (MDM), помимо этого в компании
сохранялись направления по поставкам и внедрению Системы управления
предприятием (ERP) и прочих систем на платформе 1С (Источник: Интервью
в вице-президентом компании Акскелот Власовым М. Г)
Так как в определенный момент времени в портфеле компании оказалось
большое количество не связанных друг с другом проектов, то в 2017 было
принято решения выделить бизнес-подразделения, производящие и
31
поддерживающие различные продукты в самостоятельные компании
Датареон и Градум. Компания Акселот сохранила своим основным
направлением деятельности разработку внедрение и сопровождение
логистических систем. Разделение носило не формальный, а действительный
характер. Помимо административного деления, компании Датареон и Градум
были переведены в свои отдельные офисы, и, хотя компании Акселот, Градум
и Датареон и объединены в Группу компаний Акселот, каждая из них ведет
свою независимую деятельность, разрабатывает и поставляет свои
собственные продукты.
В ходе своего развития и расширения компания Акселот уделяла
значительное внимание оптимизации своих производственных расходов. Так
как в начале 2010х годов уровень оплаты труда IT-специалистов в Москве и
других регионах России значительно различался, многие из региональных
технических вузов еще сохранили свой потенциал, а удаленная работа в
регионах еще не была популярна, в том числе в силу низкой скорости доступа
в интернет, на региональных рынках труда присутствовало достаточное
количество IT-специалистов с зарплатными ожиданиями 2-4 раза ниже, чем в
Москве. С целью воспользоваться данной ситуацией компания Акселот
создала несколько региональных подразделений, перенеся туда часть
деятельности по разработке, тестированию и поддержке своих продуктов.
Подобная оптимизация позволила значительно улучшить экономические
показатели компании.
При проведении обследовании структуры компании мы намеренно не
коснемся подразделений компании, выполняющих административные
функции, а так же Отдела маркетинга, так как их деятельность не воздействует
на объект нашего исследования.
Производящая часть компании Акселот состоит из Департамента
развития и Производственного департамента. Данная терминология
сложилась исторически и может ввести исследователя в заблуждение. Ниже