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

1. Введение

Согласно информации агентства Standish Group (CHAOS studies) американские компании ежегодно тратят около 250 млрд. долларов на разработку программного обеспечения, причем стоимость среднего проекта колеблется от 430000 до 2300000 долларов – в зависимости от размеров компании. Только 16% этих проектов завершаются в установленные сроки и не выходят за пределы оговоренного бюджета. Еще 31% проектов прекращаются, в основном, из-за проблем с качеством, что приносит 81 млрд. долларов убытков ежегодно. Другие 53% проектов завершаются с существенным превышением запланированных расходов (189%) и сроков (средний проект длится в 2 раза дольше, чем оценивалось), что приносит дополнительных 59 млрд. долларов убытков. Проекты, которые достигают состояния поставки, реализуют около 42% запланированных возможностей. [1]

В числе причин возможных неудач, по мнению разработчиков, фигурируют:
• нечеткая и неполная формулировка требований к ПО;
• недостаточное вовлечение пользователей в работу над проектом;
• отсутствие необходимых ресурсов;
• неудовлетворительное планирование и отсутствие грамотного управления проектом;
• частое изменение требований и спецификаций;
• новизна и несовершенство используемой технологии;
• недостаточная поддержка со стороны высшего руководства;
• недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.

Причина – в "тяжести" технологических процессов. "Тяжелый" процесс обладает следующими особенностями:

• необходимость документировать каждое действие разработчиков;
• множество рабочих продуктов (в первую очередь – документов), создаваемых в бюрократической атмосфере;
• отсутствие гибкости;
• детерминированность (долгосрочное детальное планирование и предсказуемость всех видов деятельности, а также распределение человеческих ресурсов на длительный срок, охватывающий большую часть проекта).

Альтернативой "тяжелому" процессу является адаптивный (гибкий) процесс, основанный на принципах "быстрой разработки ПО", интенсивно развиваемых в последнее десятилетие.

В настоящее время многие крупные компании-производители коммерческого ПО пытаются адаптироваться к изменившимся условиям, взяв на вооружение современные методологии, в том числе и так называемые «гибкие». Проблема заключается в том, что новая технология не является «серебряной пулей», способной решить все проблемы. Внедряя ее без предварительного анализа того, насколько она соответствует способу ведения бизнеса компании, какие у нее существуют ограничения, компания может серьезно ухудшить ситуацию. Как показывает накопленный опыт, успешная адаптация новых технологий требует от компании изменений (иногда достаточно серьезных) во многих аспектах ее деятельности. Целью данной работы является выявление способов сокращения цикла разработки ПО в крупной коммерческой компании путем оптимального использования современных технологий разработки. В качестве объекта исследований была выбрана компания SAP AG, признанный лидер на рынке бизнес-приложений.

2. Анализ бизнеса компании SAP AG

Компания SAP, начавшая свой бизнес в 1972 году, изначально специализировалась на создании и поддержке программного обеспечения для промышленных предприятий, исполняемого на компьютерах компании IBM (мэйнфреймах). Выпустив в 70-х годах свой флагманский продукт (SAP R/1 в 1973, SAP R/3 в 1979) SAP фактически завоевала немецкий рынок. К началу 80-х из 100 крупных немецких предприятий 50 использовали программное обеспечение SAP. В 1988 году компания была преобразована в акционерное общество и ее акции начали торговаться на Франкфуртской бирже. В том же году немецкий журнал «Manager magazine» назвал SAP компанией года. Однако настоящий успех пришел к компании с выходом в 1993 году нового поколения программного обеспечения компании (SAP R/3), который ознаменовал переход от мэйнфреймов к открытой трехзвенной архитектуре, базирующейся на концепции «клиент-сервер». К 1996 году количество инсталляций R/3 перевалило уже за 9000.

С середины 90-х доходы компании стремительно росли и к 2000 году составляли уже около 5,1 миллиардов евро, количество сотрудников превысило 20000. К этому моменту SAP имел свои представительства уже более чем в 50 странах мира. Среди клиентов крупнейшие компании с мировой известностью – Sony, Colgate-Palmolive, Coca-Cola, Unilever, Sharp и т.д. В 2008 году доходы компании составляли уже 11,5 миллиардов евро, а количество сотрудников превысило 50 тысяч человек. По состоянию на 2009 SAP занимал четвертую строчку в списке 100 мировых лидеров в производстве программного обеспечения.

Для структурирования описания бизнеса компании SAP используется концепция Коммерческой Бизнес-Модели (КМБ) [2].

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

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

Таблица 1 Комерческая бизнес-модель компании SAP AG

Анализ причин выявил значительное влияние технологии разработки на способность компании успешно внедрять новые технологии в свои продукты.

3. Новые технологии

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

Анализируемые технологии:

• RUP (Rational Unified Process) – итерационная модель разработки компании Rational Software (в настоящий момент принадлежит IBM)
• FDD (Feature-Driven Development) – разработка управляемая набором функций. Метод впервые представлен Джефом де Лукой (Jeff De Luca) и Питером Кодом (Peter Coad) в их книге «Java Modeling in Colors with UML»
• XP (eXtreme Programming) – технология экстремального программирования, разработанная Кентом Беком и получившая широкую известность в среде разработчиков
• SCRUM – эффективная методология разработки программного обеспечения. В ее основе лежит итеративная и инкрементальная работа самоуправляемых и самоорганизующихся команд.

Выводы: Каждая из рассмотренных технологий обладает определенным потенциалом в сокращении процесса разработки ПО и повышения его гибкости. Степень формализации технологий варьируется от достаточно высокой (RUP), до предельно низкой(XP). Она, в свою очередь, обратно пропорциональна требованиям к квалификации участников проекта. Не одна из этих технологий не может претендовать на универсальность. Эффективность каждой технологии зависит от контекста проекта. Вероятно, оптимальным выбором можно назвать сочетание различных техник присущих этим методологиям (включая, традиционную «водопадную» модель).
Менеджмент компании SAP AG принял решение использовать технологию SCRUM.

4. Адаптация новой технологии к условиям компании SAP AG

4.1 Интеграция в существующие бизнес-процессы

В настоящее время для управления процессом разработки ПО компания использует набор процессов и практик (framework), именуемый жизненным циклом продукта (Product Innovation Lifecycle – PIL) [3]. Основная цель PIL – базируясь на стратегических целях компании и рыночных возможностях обеспечить своевременную трансформацию первоначальной идеи в востребованный программный продукт, принимая в расчет законодательные ограничения, стандарты индустрии ПО и специфические требования к качеству компании SAP.

Процесс изменений имеет двусторонний характер: изменяется как PIL, так и методология SCRUM. Цели, решаемые на этапе интеграции:

• Изменения должны носить неразрушительный характер. Другими словами, PIL должен поддерживать как традиционную «тяжелую» технологию, так и новую «облегченную».
• Новая методология должна поддерживать особенности бизнеса компании (сложные программные продукты, распределенные команды разработчиков и т.д.). Другими словами, недостатки, присущие новым технологиям, должны быть по возможности сведены к минимуму.

4.2 Борьба с ограничениями, присущими гибким технологиям

Изначально основные постулаты методологии SCRUM отрабатывалась на небольших и средних проектах с небольшими командами. Это наложило определенные ограничения на ее применимость. Основными из них являются следующие:

• Масштабы проекта. Чем больше людей участвует в проекте, тем более формально он, как правило, должен вестись.
• Распределенные команды разработчиков. В силу специфики таких команд используются более формальные методы, чтобы компенсировать недостаток взаимного общения.
• Критичность проекта. Проекты, в которых ошибки могут приводить к тяжелым последствиям вплоть до гибели людей, должны проводиться существенно более формально, чем те проекты, в которых ошибки приводят только к временным неудобствам.
• Требования заказчика. Они существенно различаются в зависимости от отрасли и статуса организации-заказчика. Например, военные многих стран предъявляют серьезные требования к проектам по созданию ПО, которые в принципе не совместимы с новыми технологиями.

Часть из этих ограничений может быть снята путем использования специальных техник, таких как:

• Нулевой спринт. Специальная итерация на начальной стадии проекта, на которой разрабатывается архитектура верхнего уровня, которая позволяет серьезно уменьшить интеграционные риски в случае, когда в проекте участвуют несколько команд.
• Scrum of Scrums. Техника, позволяющая масштабировать процесс разработки между несколькими командами. Заключается в проведении специальных координационных Scrum митингов (аналогичных обычным), в которых участвуют представители от каждой команды.

5. Требования к SAP для успешной адаптации

5.1 Требования к технологиям

Изменения в архитектуре программной платформы. Архитектура современной системы должна поддерживать постепенные, не приводящие к остановке бизнеса, изменения на различных уровнях. Это даст возможность клиенту внедрять/развивать независимо, по мере необходимости (в зависимости от своей бизнес-стратегии). В то же время это даст возможность внедрять инновации там, где они действительно востребованы.

Изменения в технологиях программирования:

• применение нового поколения средств разработки: ускорение разработки за счет автоматизации рутинных операций, поддержка гибких процессов разработки на инструментальном уровне
• Многократное использование программных компонент
• Многократное использование знаний/опыта – архитектурные шаблоны

Изменения в технологиях тестирования:

• глубокая интеграция тестирования в процесс разработки: например, такие техники как разработка ПО управляемая тестами (Test-Driven Development)
• повышение эффективности тестирования за счет автоматизации

5.2 Изменения в управлении проектами

5.2.1 Управление содержанием.

Управление содержанием проекта осуществляется через планирование итераций. Базовый принцип управления – максимизация ценности создаваемого ПО с точки зрения клиента. Осуществляется путем приоритизации разрабатываемой функциональности.

5.2.2 Новые принципы управление проектом:

• Совместное принятие решений в условиях жесткой неопределенности. Разделение ответственности за результаты. Все решения принимаются на основании консенсуса между ключевыми участниками.
• Планирование проекта в контексте бизнес-стратегии. Главная проблема – удержать стратегические бизнес-ориентиры. Для этих целей на первом этапе проекта формируется Product vision, который отражает глобальные цели проекта.
• Обеспечение коммуникаций между основными участниками проекта. Основная цель – упростить коммуникации и сделать необходимую информацию максимально доступной.

5.3 Изменения в орг. Структуре

Чтобы использовать все преимущества новой технологии будущая структура должна обеспечивать:

• Скорость принятия решений. Минимум бюрократии (документов, согласований и т.п.). Минимальный уровень иерархии. Высший менеджмент отвечает за формирование видения (vision) и стратегии. Операционные решения (в соответствии со стратегией) принимаются на нижних уровнях иерархии. Единая схема принятия решений (одинаковая для всех уровней иерархии). Каждый сотрудник в организации знает принципы, по которым принимается то или иное решение, понимает, почему принимается конкретное решение.
• Поощрять предпринимательство. Обеспечивать необходимыми полномочиями. Обеспечивать возможность быстрой реализации новых идей путем предоставления стандартных сервисов и формулирования четких бизнес-правил (бизнес-инкубатор). Гарантировать участие в прибыли в случае успеха.
• Внутренний рынок труда. Свободное перемещение сотрудников между отдельными командами/проектами.

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

5.4 Изменение требований к квалификации участников

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

5.4.1 Компетенции участника команды

Универсал. Особенности новой методологии требуют того, чтобы каждый участник команды проекта обладал универсальными навыками (архитектор, разработчик, менеджер по управлению качеством, тестеровщик, составитель документации и т.д.)

Предприниматель. Не боялся принимать ответственные решения и брать ответственность на себя, хорошее знание рынка ПО в своей области, четкое понимание бизнеса компании

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

5.4.2 Компетенции менеджера

Новая методология рассматривает менеджера как лидера нового типа, обладающего не авторитарной властью, а властью, обеспеченной ему его авторитетом. Эффективный лидер должен обладать следующими компетенциями [4]:
• Видение целей и стратегии их достижения.
• Глубокий анализ проблем и поиск новых возможностей
• Нацеленность на успех, стремление получить наилучшие результаты.
• Способность сочувствия, понимания состояния участников команды.
• Искренность и открытость в общении.
• Навыки в разрешении конфликтов.
• Умение создавать творческую атмосферу и положительный микроклимат.
• Терпимость, умение принимать людей какие они есть, принятие их права на собственное мнение и на ошибку.
• Умение мотивировать правильное профессиональное поведение членов команды.
• Стремление выявлять и реализовывать индивидуальные возможности для профессионального роста каждого.

5.5 Взаимодействие с клиентами и партнерами

Основные принципы взаимодействия:

• Глобальная экосистема на принципах равноправного партнерства (у каждого определенная роль в цепочке создания ценностей). Ясные принципы взаимодействия и единые стандарты. Ключевой принцип участия – создание добавленной ценности в цепочке.
• Клиенты участвуют в формировании портфеля продуктов и их приоритизации. Степень участия клиента в процессе разработки варьируется от предоставления отзывов в рамках обзоров по итогам итераций, до совместного инвестирования в разрабатываемый продукт.

6. Заключение

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

Адаптация новой технологии влечет за собой серьезные изменения во многих аспектах деятельности компании. Новая технология предъявляет серьезные требования к таким вещам, как программная платформа для создания ПО, управление проектами разработки, организационная структура компании, квалификации членов проектных команд и взаимодействие с партнерами. Успешность внедрения будет во многом зависеть от способности компании SAP AG меняться в этом направлении.

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

7. Литература

1. Джек Гринфилд. Кейт Шорт. Фабрики разработки программ. Диалектика, 2007
2. Ананьин В.И. Экономика организационных изменений
3. SAP`s Product Innovation Lifecycle. www.sap.com/uk/about/quality/downloads/productinnovation.pdf
4. Архипенков С. Лекции по управлению программными проектами, Москва, 2009
5. Mike Cohn. Agile Estimating and Planning
6. Mike Cohn. Succeeding with Agile: Software Development Using Scrum
7. Стивен Р. Палмер, Джон М. Фелсинг. Практическое руководство по функционально-ориентированной разработке ПО.: Пер. с англ. – М.: Издательский дом «Вильямс», 2002
8. Лайза Криспин, Джаннет Грегори. Гибкое тестирование.Практическое руководство для тестировщиков ПО и гибких команд. М.: «Вильямс», 2010.
9. Борисов М. Scrum: гибкое управление разработкой. Открытые системы, №4 2007
10. Лилия Хаф.Методологии разработки программного обеспечения. Часть 2. Экстремальное программирование. КомпьютерПресс, №10, 2003

Copyright © 2010 Рудаков И.Б.