CC BY
167
МИХАЙЛОВА Е. А.
ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ОТ ПРИМЕНЕНИЯ МЕТОДОЛОГИИ SCRUM В ПРОЦЕССЕ УПРАВЛЕНИЯ ПРОЕКТАМИ ПО РАЗРАБОТКЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ
Аннотация. На примере ООО «65 Гигабайт» рассматривается проблема эффективности управления проектами по разработке мобильных приложений. Путем сравнительного анализа полученных от применения двух различных методологий экономических эффектов было доказано, что эффективность применения гибкой методологии Scrum выше, чем эффективность от применения жесткой методологии Waterfall.
Ключевые слова: управление проектами, методология, Scrum, Waterfall, мобильное приложение.
MIKHAILOVA E. A.
THE ECONOMIC EFFECT OF SCRUM METHODOLOGY IN MOBILE APPLICATION PROJECT MANAGEMENT
Abstract. The article considers the efficiency of mobile application project management in 65 Gigabyte Ltd. The comparative analysis of economic effects of the use of two different methodologies proved the Scrum methodology to be more efficient than the Waterfall methodology.
Keywords: project management, methodology, Scrum, Waterfall, mobile application.
Исследования проектов по разработке программного обеспечения показали, что во многих случаях стоимость и срок их реализации значительно превышали предполагаемые, а характеристики качества не соответствовали требуемым, что наносило ущерб заказчикам, пользователям и разработчикам.
Проблема эффективности управления в процессах разработки программного обеспечения усложняется вследствие возрастания разнообразия и сложности разрабатываемых программных продуктов, в частности, продуктов, разработанных на мобильных платформах. Современные проекты создания мобильного программного обеспечения характеризует нецелесообразность четкого описания и оценки реализации продукта проекта на начальной стадии в виду высокого риска изменения требований продукта, возникающих в ходе его выполнения. Использование адекватных специфике мобильных приложений и эффективных методологий управления на практике позволит повысить обоснованность управленческих решений и экономическую эффективность деятельности предприятий-разработчиков.
ООО «65 Гигабайт» оказывает услуги по разработке программного обеспечения на мобильных платформах. Менеджмент компании в своей практике управления проектами имеет опыт применения жесткой методологии Waterfall и гибкой методологии Scrum. В настоящей статье приводится описание и сравнение достигнутых экономических эффектов от применения обеих методологий. Экономический эффект будет оцениваться по двум показателям: отклонение по стоимости и отклонение по срокам.
Ключевым моментом методологии Waterfall является ее жесткий, последовательный характер, что означает, что каждая фаза разработки продукта не может начаться, если не завершена предыдущая. Данная методология требует четкого планирования в самом начале проекта, и это всегда сопровождается написанием больших технических заданий, а результат работающей программы можно наблюдать только в конце. Управлением проектом руководит менеджер, который поручает задания членам команды и устанавливает сроки и бюджет. На протяжении всего жизненного цикла команда проекта отчитывается по проделанной работе только перед менеджером, коммуникации непосредственно с заказчиком отсутствуют [1].
В качестве примера для оценки экономического эффекта от применения методологии Waterfall используется проект по разработке мобильного приложения для вызова такси. Проект был спланирован менеджером по классической модели «водопада». После того, как менеджером проекта и командой проекта были начаты работы по проектированию мобильного приложения, оказалось, что сроки выполнения задач постоянно сдвигаются, причем вслед за задачей, выполняемой с увеличением базового срока, сдвигается начало выполнения всех последующих задач. Во время реализации проекта фиксировалась фактическая длительность каждой задачи, после чего был построен реальный календарный план.
Сравнение запланированных и фактических сроков выполнения проекта в процессе выполнения работ продемонстрировано в таблице 1.
Все пять задач имели существенные отклонения по длительности, что повлекло за собой задержку срока сдачи проекта и увеличение стоимости проекта. С помощью наблюдения за ходом выполнения проекта были выявлены и систематизированы причины задержек задач проекта.
Сравнение запланированных и фактических сроков проекта по разработке мобильного приложения для вызова такси
Задачи Базовое начало Базовое окончание Начало Окончание Базовая длительность, день Длительность, дней
Проектирование 14.07.2013 08.08.2013 14.07.2013 29.08.2013 20 33
Дизайн 11.08.2013 22.08.2013 01.09.2013 18.09.2013 10 14
Написание тех. задания заказчиком 11.08.2013 15.08.2013 01.09.2013 19.09.2013 5 15
Разработка API заказчиком 14.07.2013 08.08.2013 14.07.2013 20.10.2013 20 92
Разработка МП 18.08.2013 10.10.2013 23.09.2013 05.12.2013 40 54
ИТОГО: 95 208
Задача «Проектирование мобильного приложения». Базовая длительность предполагалась равной 20 дням, фактическая составила 33 дня.
Длительное формирование требований, стремление к минимизации рисков путем полной аналитики возможных разногласий в будущем привело к задержке момента согласования финального прототипа и готовности приступить к следующему этапу. Продолжительное время вносились корректировки и добавления в прототип, а как следствие, в требования к мобильному приложению. Длительная по времени неопределенность заказчика в предоставлении своих требований менеджеру проекта по предполагаемым функциям мобильного приложения.
Задача «Дизайн мобильного приложения». Базовая длительность предполагалась равной 10 дням, фактическая составила 14 дней.
Во время предыдущего этапа директор компании заказчика не участвовал в формировании требований к мобильному приложению, но на текущем этапе он решил внести собственные пожелания. На данном этапе оформлялась визуализация мобильного приложения, вносились многочисленные корректировки по желанию заказчика, что повлекло за собой задержку сроков.
Задача «Подготовка Технического задания заказчиком». Базовая длительность предполагалась равной 5 дням, фактическая составила 15 дней. Задержку на данном этапе спровоцировала неопределенность заказчика в своих требованиях к конечному продукту.
Задача «Разработка API заказчиком». Базовая длительность предполагалась равной 20 дням, фактическая составила 92 дня.
На данном этапе заказчик должен был разработать API (интерфейс взаимодействия между сервером заказчика и мобильным приложением). Но в виду высокой загрузки ответственных программистов на других проектах и неопределенности функционала мобильного приложения на данном этапе произошла задержка. В виду задержки предоставления заказчиком работоспособного API менеджер проекта вынужден был направить разработчика на выполнение другого проекта сроком на 27 дней.
Задача «Разработка мобильного приложения». Базовая длительность предполагалась равной 40 дням, фактическая составила 54 дня.
На данном этапе задержка была спровоцирована не готовностью API, а также разным толкованием технического задания (ТЗ) исполнителем и заказчиком. Исполнитель считал, что спорные задачи по разработке выполнены корректно, по крайней мере предмет спора не был описан в ТЗ, в то время как заказчик посчитал, что такой очевидный пункт не стоило даже подробно описывать. Еще одной задержкой на данном этапе послужили явные изменения бизнес-требований программного обеспечения, вызванными корректировками отдела маркетинга заказчика. Многие из нововведений повлекли за собой изменения в архитектуре приложения. Большое количество времени ушло на коммуникацию между исполнителем и заказчиком во время тестирования. Заказчик очень долго тестировал промежуточные и финальный результаты. Все издержки со стороны заказчика компенсировались путем заключения дополнительных соглашений к договору.
Сравнение запланированного и фактического бюджета проекта выполнения проекта в процессе выполнения работ продемонстрировано в таблице 2.
Проанализировав данный проект, можно отметить следующее. Главным критерием успешности проекта являлось качество. Под качеством подразумевалась возможность выявления и исправления ошибок на ранних этапах проекта, а также полное соответствие результатов проекта требованиям заказчика. Как результат, длительность и бюджет проекта автоматически увеличивались из-за постоянных доработок программного обеспечения.
Сравнение запланированного и фактического бюджета проекта по разработке мобильного приложения для вызова такси
Задачи внутри компании Специалист Стоимость часа спеца, руб Базовое количество часов Количество часов Базовые затраты, руб Затраты, руб
Проектирование Дизайнер 900 40 60 36000 54000
Дизайн Дизайнер 900 20 30 18000 27000
Разработка МП Разработчик 900 320 432 288000 388800
Управление проектом Менеджер проекта 900 57 78 51300 70200
ИТОГО: 437 600 393300 540000
В середине и конце проекта команда разработчиков находилась в постоянно стрессовом состоянии, так как отсутствие полноценной коммуникации с другими работниками заказчика повлекло за собой субъективное понимание технического задания. В результате менеджером проекта было решено назначить им дополнительный объем работы, но, несмотря на это, производительность работников была ниже предполагаемой из-за человеческого фактора.
Отклонение по времени составляет 113 дней (в базовом плане предполагалось 95 дней, фактически вышло 208 дней);
В плане предполагалась стоимость проекта равная 393 300 рублям, фактическая составила 540 000 рублей, из которых 146 700 рублей - запросы на изменения.
Ввиду специфики данной методологии тестирование и отладка программного обеспечения происходит намного позже разработки, что автоматически исключает возможность обнаружения ошибок на ранних этапах и их дальнейшее исправление. Поэтому критерий качества в данном случае зависит напрямую от удовлетворения заказчика от полученного, в конечном счете, продукта.
Таким образом, чтобы действительно достичь желаемого уровня качества, длительность проекта пришлось увеличить на 119%, а стоимость на 37%.
Клиент и менеджер проекта стремились минимизировать возможные, нежелательные отклонения от требуемого качества (то есть, целевой результат подразумевает соответствие продукта ожиданиям заказчика), следовательно, для того, чтобы отклонения по качеству (которое было выбрано наиболее приоритетным из всех критериев проекта), длительность проекта и его бюджет пришлось увеличить.
Таким образом, если определенные в начале проекта требования не меняются, то руководствоваться техническим заданием целесообразно. Как выяснилось, проблема заключается в том, что на деле ни один проект по разработке мобильного приложения невозможно спроектировать таким образом, чтобы предугадать все требования пользователей и его функционал. Помимо всего прочего, если что-то было упущено в работе проекта на его начальных стадиях, исправить это, находясь на завершающих этапах, очень сложно и требует дополнительных затрат.
В качестве примера для оценки экономического эффекта от применения Scrum используется аналогичный проект по разработке мобильного приложения для вызова такси, заказанный другим клиентом, с некритичным изменением функционала. Следует отметить, что количество специалистов и в том и в другом проекте одинаково.
Методология Scrum предполагает применение итеративного подхода к разработке продукта. По истечении каждой итерации команда подготавливает готовую к использованию программу с определенным на старте итерации функционалом.
Проект проходил через следующие этапы:
- представитель заказчика подготавливает все требования к продукту;
- после сбора требований и ознакомления с документацией заказчика менеджер проводит нулевую итерацию для оценки существующих на данный момент задач, в результате создается список задач для реализации продукта;
- каждая итерация начинается с его планирования, т.е. команда определяет количество времени, которое необходимо каждому участнику для выполнения заданий;
- выбранные задания переносятся в список задач итерации и, если надо, детализируются членами команды;
- во время планирования итерации участники команды обсуждают общую идею выполнения задач, их коррелированность с другими специалистами и прочее;
- в течение итерации команда выполняет задания, каждый день отчитываясь друг другу о выполненной работе во время ежедневного собрания;
- в конце итерации команда демонстрирует настроенный функционал менеджеру проекта и представителю заказчика.
По базовому плану процесс разработки приложения должен был занять 12 итераций, что соответствует 120 рабочим дням, при условии отсутствия внесения изменений заказчиком.
В конечном итоге весь процесс создания мобильного приложения занял 13 спринтов, что соответствует 130 рабочим дням.
Отклонения фактического плана от базового, построенного по Scrum, представлены в таблице 3.
Таблица 3
Отклонения фактического плана от базового плана
Задачи Базовое начало Базовое окончание Начало Окончание Базовая длительность, день Длительность, дней
Проектирование 17.02.2014 10.03.2014 17.02.2014 10.03.2014 16 16
Дизайн 11.03.2014 30.03.2014 11.03.2014 30.03.2014 14 14
Написание ТЗ заказчиком 10.03.2014 20.03.2014 10.03.2014 20.03.2014 10 10
Разработка API заказчиком 17.03.2014 30.04.2014 17.03.2014 05.14.2014 33 36
Разработка МП 30.03.2014 30.05.2014 30.03.2014 18.04.2014 46 54
ИТОГО: 120 130
Отклонения по длительности были зафиксированы по задачам «Разработка API» и «Разработка МП» ввиду задержек на этапах тестирования.
Проанализировав длительности базового и фактических планов, можно заметить, что отклонение по длительности составило 8%.
Так как проект, реализованный при помощи Scrum, не предполагает наличие запросов на изменение, время выполнения которых оценивается в Waterfall менеджером проекта, важно отметить, что отклонения по стоимости проекта с предлагаемой методологией невелики, так как происходит только доплата за дни задержек. Базовая стоимость проекта оценивается в 434 700 000 рублей, а фактическая - в 504 300 рублей, таким образом, отклонение по стоимости равно 16%.
Как было неоднократно отмечено ранее, применение итеративной методологии управления проектами целесообразно тем, что уточнение и демонстрация очередной версии программного обеспечения происходит довольно часто, после окончания очередной итерации. При таком подходе, очевидно, что возникающие на ранних этапах ошибки могут быть сразу же исправлены (в отличие от Waterfall, где ошибки можно обнаружить только на этапе тестирования). Кроме того, получаемый в конце проекта продукт больше соответствует требованиям заказчика. Соответственно, оперируя данными суждениями, можно отметить, что отклонение по качеству продукта, полученного с помощью Scrum намного меньше отклонения по качеству продукта, полученного с помощью Waterfall:
< ^waterfall
В Таблице 4 представлено соотношение общих критериев двух методологий: Scrum и Waterfall.
Несмотря на то, что базовая длительность проекта, реализованного с помощью Scrum больше базовой длительности проекта, реализованного с помощью Waterfall, отклонения и по длительности и по стоимости у проекта, выполненного с помощью Scrum существенно меньше, чем у Waterfall при очевидном выигрыше в качестве мобильного приложения.
Таблица 4
Соотношение общих критериев Waterfall и Scrum
Длительность Стоимость
(дней) (руб.)
Модель Качество Базовая Фактическая Отклонени е (%) Базовая Фактическая Отклонение (%)
Waterfal Scrum < ^waterfall 95 208 119% 393 540 37%
l 300 000
Scrum Scrum < waterfall 120 130 8% 434 504 16%
700 300
Проведенный анализ показывает, что в условиях быстро меняющихся и нечетко определенных требованиях использование Scrum в управлении проектами по разработке мобильных приложений является наиболее эффективным как для вендора, так и для заказчика. Говоря о вендоре, стоит отметить, что слаженная работа, которая определяется самими специалистами, выполняющими ее, намного больше стимулирует исполнителей на качественное решение задач, нежели постоянные поручения менеджера проекта и пребывание в вечном стрессе. Для заказчика и исполнителя выгода очевидна: проект внедряется быстрее, качественнее и с меньшими затратами по сравнению с традиционным методом.
ЛИТЕРАТУРА
1. Избачков Ю., Петров В. Информационные системы: учебное пособие. - СПб.:
Питер, 2006. - 656 с.
