Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

На правах рекламы
2004 г.

Принципы совершенствования производственных процессов по разработке ПО

Ян Спенс (Ian Spence), Технический директор группы управления процессами и проектами,
Rational Services Organization, Великобритания

Нет ничего более трудного, чем введение нового порядка. Автору новаций придется столкнуться с враждебностью тех, кому было хорошо раньше, и с равнодушием тех, кому может стать хорошо в новых условиях.
- Никколо Макиавелли, 1513 г.

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

Изменение производственных процессов есть изменение организационной структуры

Прежде чем приступить к обсуждению программ совершенствования производственных процессов (Process Improvement Programs) и их результатов, следует сделать шаг назад и познакомиться с основными концепциями, которые используются в любой компании, разрабатывающей программное обеспечение. В основе всей организации лежат четыре фундаментальных понятия:

    ·
  • Клиенты
  • Продукты
  • Организационные единицы
  • Проекты

Между этими четырьмя понятиями имеются следующие взаимосвязи:

  • проекты (projects) создают и изменяют продукты (products);
  • проекты используют ресурсы организационных единиц (organizational units);
  • организационные единицы организуют ресурсы и содействуют клиентам (customers), проектам и продуктам;
  • клиенты потребляют и заказывают продукты;
  • клиенты обеспечивают рынок и формируют требования к создаваемым продуктам.

В этой модели отсутствует то, что связывает воедино эти понятия, - это корпоративная культура (см. рисунок).

Рис. Корпоративная культура составляет инфраструктуру компании-разработчика ПО

Корпоративную культуру можно рассматривать как философию и методологию, которые совместно формируют облик компании, спектр производимых ею продуктов, а также круг ее клиентов.

Для компаний, бизнес которых связан с программной инженерией, корпоративная культура представляет собой сочетание базовой деловой культуры и методики ведения бизнеса, культуры вышестоящей компании, операционных процедур и среды разработки программного обеспечения (software development environment). Последняя включает в себя все то, что нужно для разработки проекта, развертывания и сопровождения продукта, в частности, производственные процессы, инструментальные средства, руководящие принципы, шаблоны и технологии.

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

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

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

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

Почему так трудно изменить организационную структуру?1

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

К несчастью, людям свойственно противиться переменам. На деле, то из-за инертности, то из-за страха перед неизвестным, люди часто противодействуют изменениям или, по меньшей мере, замедляют до приемлемого с их точки зрения темпа. Чтобы изменить организационную структуру, нужно представлять себе эти силы и заставлять их помогать, а не мешать изменениям. В своей статье "Affecting Organizational Change""2 Роджер Хебден (Roger Hebden) сформулировал движущие силы изменений простой формулой:

неудобство + желание = изменение

Основной смысл ее заключается в том, что изменение в конечном итоге вызвано эмоциями. Испытываемое неудобство и желание его исправить являются движущими силами для совершения изменения. Неудобство служит катализатором, инициирующим изменение, а желание - той силой, которая ведет нас к цели. Для успешного развития необходимо понимать и уметь управлять уровнем восприятия неудобства и степенью желания. Д. Коннор назвал это "устранением боли и подбором лекарства".3

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

Изменения не происходят по одной лишь указке руководства. Легко рассуждать о проблемах и решениях. Есть одно общее требование к тому, какими должны быть проекты: каждый проект должен следовать методологии Rational Unified Process. Однако само по себе оно мало чем помогает изменениям.

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

  • Определить ответственных за изменения (агентов) на различных уровнях организационной структуры. Это люди, которые возьмут на себя осуществление изменений.
  • Сформулировать глубинную природу проблемы. Агенты, осуществляющие изменения, должны понять истинную природу неудобства и донести ее до всех остальных.
  • Спланировать изменения в виде небольших, разумных и измеримых шагов, описывающих как цель, так и путь к ее достижению.> Планы должны быть сбалансированными и учитывать как необходимость достижения немедленных тактических улучшений, так и долгосрочные стратегические цели.
  • Сообщать об изменениях в терминах осязаемых, поддающихся количественному измерению достижений и действий так, чтобы это было понятно на всех уровнях организации.

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

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

Именно такие проблемы нетехнического характера препятствуют многим компаниям в их попытках фундаментального изменения среды разработки ПО.

Внедрение программы совершенствования процессов

Изменения производственных процессов оказывают более глубокое воздействие на компании и сотрудников, нежели изменения технологий и инструментальных средств. Ведь они затрагивают основные убеждения и ценности людей, меняя представления персонала о работе. В ряде случаев изменения могут доходить даже до системы поощрений, физических условий труда, культуры бизнеса и стиля поведения. Изменения также воздействуют на работу на уровне проектов, подразделений и взаимоотношений с другими организациями. Как отмечает Айвар Джейкобсон в своей книге "Software Reuse: Architecture, Process, and Organization for Business Success"4, подобного рода изменение процессов равносильно модернизации самой структуры разработки ПО.

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

Такая программа должна затрагивать следующие аспекты:

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

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

  • Руководящие работники, отвечающие за эффективность организации процесса разработки ПО. Любая программа совершенствования производственных процессов должна получать поддержку со стороны руководства, поэтому руководители должны понимать, с какой целью проводятся изменения, какой будет прибыль от вложенных средств, когда и как будет осуществляться развитие, чего следует ожидать и какие действия по управлению следует предпринимать.
  • Клиенты компании, как внутренние, так и внешние. Возможно, их понадобится информировать об изменениях в организационном процессе, поскольку это может оказать воздействие на то, как и когда будут учитываться их мнения и как будут доставляться программные продукты.
  • Другие составные части компании также могут быть затронуты. Иногда изменения в одном секторе компании вызывают сопротивление и скептицизм со стороны других секторов, поскольку те могут не понимать причин для осуществления изменений. Даже если прямого влияния на программу с их стороны нет, игнорирование других составных частей компании может привести к проблемам политического характера.

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

Подход к совершенствованию процессов на основе практического опыта

Наш опыт показывает, что повысить шансы программы Process Improvement Program на успех может применение ряда основных принципов:

  • Запускайте программу как коммерческую - думайте о возврате инвестиций (ROI, Return on Investment).
  • Оцените существующую среду.
  • Используйте готовые, проверенные решения - не изобретайте велосипед.
  • Добивайтесь измеримых, постепенных улучшений.
  • Сосредоточьтесь на проектах и продуктах, а не на организационной структуре.
  • Применяйте методы убеждения, а не принуждения. Помогайте, а не критикуйте.
  • Распределите ответственность за процесс.
  • Информируйте и вовлекайте людей.

Далее каждый из этих принципов будет рассмотрен более детально.

Запускайте программу как коммерческую - думайте о возврате инвестиций

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

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

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

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

Осмысление существующей среды

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

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

Без понимания этих основ нельзя принимать решения о расстановке приоритетов по совершенствованию процесса и о критериях оценки усовершенствований.

Используйте готовые, проверенные решения - не изобретайте велосипед

Программа совершенствования процесса должна основываться на прочном фундаменте. Для его построения есть три источника:

  • То, что компания делает хорошо. Заимствуйте лучшие практические подходы из самых успешных проектов.
  • Методики и продукты, наиболее прогрессивные в отрасли.
  • Опыт людей, участвующих в программе.

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

Добивайтесь реальных, постепенных улучшений

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

Например, возможен такой подход:

  • Главное направление первой итерации: совершенствование сбора и управления требованиями.
  • Главное направление второй итерации: анализ и проектирование приложений и их компонентов.
  • На последующих итерациях можно разрабатывать и реализовывать другие компоненты среды.

Сосредоточьтесь на проектах и продуктах, а не на организационной структуре

Во многих инициативах по совершенствованию процессов уделять внимание организационной структуре, связанной с поддержкой желаемого процесса, пытаются еще до того, как сам процесс будет проверен или одобрен. При этом рассуждают так: если расставить все компоненты по нужным местам, они автоматически будут правильно работать и выдавать правильные результаты. Другой типичный вариант рассуждений: если построить структуру, все остальное заработает само по себе. Такой подход в лучшем случае является наивным, а в худшем - пагубным.

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

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

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

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

Применяйте методы убеждения, а не принуждения. Помогайте, а не критикуйте

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

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

Руководитель-наставник должен сосредоточиться на передаче знаний и делегировании ответственности участникам команды, работающей над проектом, и в конечном итоге - нивелировании своей роли. Наставники также должны помнить о своей доле ответственности за реализацию программы совершенствования процесса, включая:

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

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

Распределение ответственности за производственный процесс

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

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

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

Информирование и привлечение людей

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

Для предотвращения такой нежелательной ситуации можно предпринять следующие действия:

  • Сделайте ожидания максимально реалистичными. Не следует переоценивать новый процесс или новые инструментальные средства.
  • Разъясните необходимость изменений. Сделайте так, чтобы люди знали, какие проблемы, нуждающиеся в решении, встают перед компанией. Какие изменения в технологии требуют нового процесса и новых инструментов? Какой выигрыш люди получат от использования этих новых инструментов и производственного процесса?
  • Проинформируйте всех сотрудников компании о том, что происходит. Эта информация не должна быть излишне подробной, но важно, чтобы люди знали о планируемых изменениях.
  • Помните о заинтересованных лицах и партнерах, в особенности, о клиентах и спонсорах. Если вы, например, переходите с модели разработки по методике "водопада" (когда предыдущий этап полностью завершается до начала следующего) к итеративной модели разработки, заинтересованные лица должны понимать, как будет осуществляться руководство итеративной разработкой проекта и как будет измеряться успех. При итеративной разработке проекта не следует ожидать полностью законченного решения на раннем этапе, при этом требования могут учитываться по-разному.
  • Привлекайте ведущих специалистов к работе над изменениями. Сделайте их ответственными за реализацию составных частей процесса.
  • Проводите необходимое обучение, познакомив участников проекта с новым процессом и с новыми инструментальными средствами. В любом случае им нужно будет представлять, как функционирует процесс и как пользоваться новыми инструментами.

Программа совершенствования процессов как агент изменения

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

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

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

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

Пользуйтесь существующей средой разработки программного обеспечения (т.е. применяйте то, что у вас есть). Используйте концепции, методы, инструменты и методики предлагаемого решения для создания самого решения. Например:

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

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

Жизненный цикл совершенствования процесса

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

Рис. Цикл функционирования программы совершенствования процессов

Current process Текущий процесс
1. Assess Current State 1. Оценка текущего положения
2. Set (or Revise) Goals 2. Установка (или корректировка) целей
3. Identify Risks 3. Определение рисков
4. Plan Process Implementation 4. Планирование реализации процесса
5. Execute Process Implementation 5. Осуществление реализации процесса
6. Evaluate Process Implementation 6. Оценка реализации процесса
New Process Completely Implemented Новый процесс полностью реализован

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

Рис. Непрерывное совершенствование процесса

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

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

Другим важнейшим источником для получения руководящих указаний является Институт проблем разработки программного обеспечения (Carnegie Mellon Software Engineering Institute). Помимо создания модели Capability Maturity Model® for Software (CMM, модель зрелости для ПО), которая сама по себе выступает в качестве каркаса для совершенствования процессов, Институтом программной инженерии SEI (Carnegie Mellon Software Engineering Institute) была разработана модель IDEAL, которая служит ориентиром при планировании и реализации эффективной программы совершенствования процесса разработки ПО.5 Эта модель, основанная на CMM, предлагает более формальный и подробно документированный итеративный жизненный цикл, чем простая модель, представленная на рис. 3.

Выводы

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

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

Советы по стратегии достижения успеха:

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

Участникам проектных команд, отвечающим за реализацию программы совершенствования процессов, следует:

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

Не следует пытаться построить универсальный производственный процесс на все случаи жизни. Процесс всегда будет требовать локальной адаптации; при этом он в нем видятся три составляющие:

  • инфраструктура для быстрой конкретизации процесса применительно к проектам;
  • общая база и минимальные критерии приемлемости для всех проектов;
  • библиотека инструментальных средств и методик, которые могут быть применены в проектах.

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

Литература

Книги и статьи
  1. D. Conner, Managing at the Speed of Change. Random House, 1992.
  2. J. Jellison, Overcoming Resistance: A Practical Guide to Producing Change in the Workplace. Simon & Schuster, 1993.
  3. Ivar Jacobson, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.
  4. Roger Hebden, "Affecting Organizational Change." Rational Software, 1995.
  5. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber, "Capability Maturity Model for Software, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, февраль 1993.
  6. Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, and Marilyn W. Bush, "Key Practices of the Capability Maturity Model, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, февраль 1993.
  7. Robert McFeeley, IDEAL: A User's Guide for Software Process Improvement. Software Engineering Institute CMU/SEI-96-HB-001, февраль 1996.
Rational Unified Process

При написании этой статьи активно использовались материалы из следующих разделов курса Environment Discipline в составе базы знаний Rational Unified Process (RUP):

  • Concepts: Effect of Implementing a Process ("Концепции. Эффект от реализации процесса")
  • Concepts: Mentoring ("Концепции. Руководство и наставничество")
  • Concepts: Managing Organizational Change ("Концепции. Управление организационными изменениями")
  • Concepts: Environment Practices ("Концепции. Действующие методики и правила")
  • Concepts: Implementing a Process in an Organization ("Концепции. Реализация процесса в организации")

Институт программной инженерии Carnegie Mellon Software Engineering Institute

Для получения более подробной информации о программах совершенствования процессов, а также о моделях Capability Maturity Model for Software и IDEAL посетите сайт института Carnegie Mellon Software Engineering Institute:

Примечания
  1. Этот раздел взят из документа Rational Unified Process: Environment/Concepts/Managing Organizational Change, который, в свою очередь, основан на статье Роджера Хебдена (Roger Hebden) "Affecting Organizational Change" (см. примечание 2.).
  2. Roger Hebden, "Affecting Organizational Change." Rational Software, 1995.
  3. D. Conner. Managing at the Speed of Change. Random House, 1992.
  4. Ivar Jacobson, Martin Griss and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, 1997.
  5. См. статью Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, "Capability Maturity Model for Software, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, февраль 1993; и Mark C. Paulk, Charles V. Weber, Suzanne M. Garcia, Mary Beth Chrissis, Marilyn W. Bush, "Key Practices of the Capability Maturity Model, Version 1.1." Software Engineering Institute, CMU/SEI-93-TR-25, DTIC Number ADA263432, февраль 1993.

По вопросам приобретения программного обеспечения IBM Rational просьба обращаться в компанию Аплана, группа компаний АйТи: тел. 748 1345, rational@aplana.com, http://rational.aplana.ru

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...