Скорые (Agile) методики приобрели такую популярность, что неудивительным становится желание строить на них свою маркетинговую политику. Главной темой на недавнем форуме Teradata 2016 стало использование agile-подходов в процессах аналитики.

«Agile – не только новый подход к реализации проектов, это в первую очередь переворот в мышлении и культуре организации. Не все готовы к тому, что быстрая реакция на изменения ценится гораздо больше, чем умение следовать плану», — заявил Стивен Бробст, главный технический директор Teradata. По его словам, эти методики действительно работают — процессы становятся более гибкими. Более того, иногда имеет смысл формировать гибридные методики, например Scrumban (сочетание Scrum и Kanban), этот подход используется внутри Teradata.

Быстрота реакции лежит в основе и новой концепции «чувствующего предприятия» (Sentient Enterprise), продвигаемой Teradata. Она представляет организацию как единый организм, который воспринимает окружающий мир: компания должна чувствовать сигналы внешней среды, адекватно реагировать на получаемые данные.

Николай Трошин, начальник отдела управления данными МТС, считает, что многие процессы можно позаимствовать из agile-методик: «Вот уже год мы работаем по методике Scrum: спринты, итерации, инкрементации, фокус на результат», — говорит он. При этом надо понимать, что само по себе внедрение скорых методик – тоже agile-проект, сразу его реализовать не получится, необходимо несколько итераций. Действительно, Scrum «с ходу» не ложится на аналитические процессы, так как изначально ориентирован на разработчиков, однако его вполне можно адаптировать.

По мнению Трошина, скорые методики хорошо сочетаются с культурой использования открытых платформ. «Надо обязательно пробовать открытые решения, а если не получается – переходить на коммерческие продукты. Мы сочетаем эти подходы», — сообщил Трошин.

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

«Мы принимаем участие во многих инновационных проектах, включая блокчейн, но крайне осторожно подходим к их продуктивному использованию. Далеко не все инноваторы могут похвастаться прибылью, инвестиции в непроверенные технологии очень рискованны», — подчеркнул Сергей Адаменко, вице-президент и директор по данным Сбербанка.

В нынешнем году в Сбербанке создано подразделение по работе с данными и фабрика данных. Но главное – работа с данными превратилась в отдельный вид профессиональной деятельности. Большие Данные дали ощутимый эффект в плане борьбы с мошенничеством. Второе важное направление работ – корректность маркетинговых акций: в банке прекрасно осознают, что навязчивая реклама способна отвратить даже лояльного пользователя. «Я извиняюсь перед теми, кому одни и те же предложения демонстрировались несколько раз. Это означает, что создаваемые нами модели еще не достигли идеала», — признался Адаменко.

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

Дмитрий Первухин, начальник управления обработки данных и формирования отчетности ВТБ24, рассказал о планах переноса корпоративного хранилища Teradata в облако. За семь лет строительства хранилища данных появились серьезные вызовы — гигантские объемы данных стали влиять на производительность систем. Крайне важное значение приобрели регламенты загрузки данных, любой сбой в них влияет на ежедневную работу пользователей, критичные приложения могут конкурировать за ресурсы с пользователями. Кроме того, мощностей решения заметно не хватает в период пиковых нагрузок, а в остальное время много их простаивает.

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

Главной темой конференции Busines Information Security Summit 2016, прошедшей 23 сентября в Москве, стало обеспечение безопасности информационных систем в условиях постоянного изменения объектов защиты. Как отметил Рустэм Хайретдинов, заместитель генерального директора компании InfoWatch, все чаще бизнес-приложения разрабатываются и модернизируются по методологии Agile, а изменения в них, пусть и небольшие, вносятся едва ли не ежедневно.

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

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

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

От лица практиков, приверженных методологии Agile, выступил Райнхольд Вохнер, руководитель cлужбы информационной безопасности Raiffeisen Bank, рассказавший, как новый подход меняет взаимодействие структур банка друг с другом и с внешним миром. На подходе, по его словам, два «вызова» системам безопасности — финтех-компании и Интернет вещей.

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

Несколько скептичнее по отношению к Agile оказался Станислав Витечек, исполнительный консультант по архитектуре и интеграции умного автомобиля и мобильных онлайн-сервисов в SkodaAutomotive. Он полагает, что применение скоростных методов к критически важным инфраструктуре и приложениям породит больше проблем, чем решит: слишком сложно отследить в них все взаимодействия, которые могут быть затронуты быстрым обновлением, в том числе средств информационной безопасности. А вот работу с пользовательскими приложениями и встроенными в автомобиль системами перевести на Agile можно. Как заметил Витечек, уязвимости будут всегда, идеальную систему безопасности не построишь. Главное — минимизировать ущерб.

Немного про импортозамещение

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

Cписок критериев «отечественности» ПО, имеющийся в утвержденных министерством «Правилах формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных», весьма краток и конкретен. Скажем, для «обычного» программного обеспечения, в составе которого нет функций, связанных с защитой конфиденциальной информации или с гостайной (попадание последних в реестр вообще не предусмотрено), их всего три. Софт, для того чтобы быть признанным российским, должен более чем на 50% принадлежать российским физическим или юридическим лицам, а суммы выплат за календарный год по лицензионным и иным договорам зарубежным обладателям прав на используемые в ПО технологии не должны превышать 30%. Ну и программное обеспечение должно быть «правомерно введено в гражданский оборот на территории Российской Федерации».

При всей простоте критериев, без конфликтов при определении «отечественности» ПО, не обошлось. Например, было отвергнуто решение WorksPad компании «МобилитиЛаб», входящей в группу «АйТи» как содержащее «ключевой функционал» иностранного производства. Тагир Яппаров, председатель совета директоров «АйТи», отметил, что его компания понесла в результате убытки, но не пошла в суд, а вступила в диалог с экспертами. Сейчас в реестре присутствует WorksPad One, один из продуктов семейства WorksPad.

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

Идея плодотворная, поскольку, строго говоря, едва ли не любая программа из реестра может быть названа надстройкой над Windows.

Аналитики Gartner считают DevOps определенной философией, для следования которой необходимы изменения культуры коммуникаций в ИТ-департаментах. Однако инструменты автоматизации имеют не меньшее значение для успешного перехода к DevOps. По прогнозам Gartner, объем рынка таких систем в 2015 году достигнет 2,3 млрд долл., рост по сравнению с прошлым годом составляет 21,1%. Востребованность этих продуктов вполне объяснима – аналитики полагают, что DevOps перестает быть нишевой стратегией крупных облачных провайдеров и в 2016-м будет реализована в четверти компаний из списка Global 2000.

Интерес к DevOps проявляют многие поставщики решений автоматизации процессов разработки и эксплуатации ИТ-сервисов. Однако не удивительно, что HP, с ее солидным бэкграундом в обеих этих сферах, а также в области комплексного управления ИТ, стала, фактически, первопроходцем на российском рынке с точки зрения предложения единого универсального подхода к реализации DevOps, как в свое время была первой, кто начал систематически продвигать в нашей стране принципы управления ИТ-сервисами (ITSM).

В чем особенности стратегии DevOps в Hewlett Packard Enterprise и какие компания предпринимает шаги по ее реализации на российском рынке, рассказывает Андрей Кутуков, директор департамента программных решений HPE в России.

— Как в НРE определяют DevOps?

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

— Что послужило стимулом к тому, что компания начала активно заниматься этим направлением?

Актуальность темы для рынка. Концепция DevOps известна не первый год. Программные решения HPE для управления требованиями, автоматизации тестирования, повышения эффективности процессов эксплуатации ИТ развиваются уже много лет. Но наступил момент, когда и бизнес, и ИТ-организации начали осознавать, что на разработку, тестирование и эксплуатацию надо смотреть как на сквозной процесс – только в этом случае удастся ускорить выпуск новых ИТ-сервисов, без которых бизнес сегодня может потерять конкурентоспособность.

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

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

— Что предлагает НРE для реализации DevOps?

Год назад в HPE была создана специальная группа, в основном из европейских специалистов, которая работает над пакетом предложений HP DevOps. Перед ними стояла задача комплексного описания процессов DevOps на всех уровнях – от общей архитектуры решения до конкретных интеграционных сценариев.

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

Портфель HPE DevOps постоянно развивается и расширяется. Этим летом, например, был выпущен так называемый DevOps Model Office – универсальное решение, интегрирующее множество продуктов как НРE, так и сторонних производителей для демонстрации различных сценариев DevOps. Решение может быть представлено в виде виртуальной среды или развернуто на площадке заказчика. Это дает возможность на практике увидеть непрерывную интеграцию (Continuous Integration) и непрерывное предоставление (Continuous Delivery) как составные части DevOps.

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

— Насколько подход DevOps востребован в России? Кто ваши потенциальные заказчики?

В России очень большой интерес к этой концепции. Мы проводим семинары по DevOps, и многие заказчики просят нас оценить текущее состояние их ИТ-подразделений с точки зрения отношений между группами разработки и эксплуатации, построить для них «дорожную карту». Сейчас такая работа ведется с несколькими крупными компаниями, и, думаю, когда мы сможем рассказать рынку о ее результатах, это даст еще один толчок к продвижению DevOps в России.

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

— Планируется ли привлечение партнеров к реализации проектов по HPE DevOps?

Пока мы рассчитываем на собственные силы, но проводим обучение партнеров, рассказываем им о DevOps как о новой и перспективной области.

— Управление ИТ всегда было одним из ключевых направлений для HP Software. Есть ли взаимосвязи между HPE DevOps и другими областями ИТ-управления, которыми занимается компания, например, ITSM?

Безусловно. И последнее время нам в этом очень помогает IT4IT – концепция единой архитектуры управления ИТ, которую разрабатывает и продвигает консорциум The Open Group. HPE принимает активное участие в этой работе. DevOps, как и ITSM, является одним из аспектов архитектуры IT4IT. Очень ценно то, что в ее разработке ведущую роль играют заказчики, в частности, инициатором создания рабочей группы по IT4IT в The Open Group была компания Shell.

DevOps и IT4IT входят в список основных направлений, которые программный департамент Hewlett Packard Enterprise намерен продвигать сегодня на рынок.

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

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

Хотя принципы скорой (agile) разработки изначально были предложены создателями программного обеспечения, сегодня они применимы практически в любой сфере. В их основе лежат сотрудничество, открытые коммуникации, доверие и независимость, эффективность и непрерывная выдача результатов. Все это способно сформировать долгосрочный позитивный эффект почти в каждой структурной части вашей организации. На прошедшей недавно в Вашингтоне конференции Agile Alliance 2015 старший консультант компании Industrial Logic Тим Оттингер изложил шесть принципов концепции скорой разработки, которые можно использовать фактически повсеместно.

Помните: иногда работа выглядит не так, как вы привыкли

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

«Работа заключается в том, чтобы думать, а не стучать по клавишам, — указал Оттингер. – Мозговые штурмы, обсуждение и даже простое пребывание вместе с членами команды – все это часть работы. Иногда самые удачные идеи и решения приходят в голову не во время многочасового написания кода, а во время прогулки. Нужно считать не время, в течение которого пальцы бьют по клавишам, а время, когда остаются в игре».

Формируйте ценности как можно раньше и как можно чаще

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

«ВременнЫе ограничения скорого подхода снижают вероятность аварий, ошибок, выбора неверного направления и прочих проблем, – подчеркнул Оттингер. – Рамки сужаются. Будучи разработчиками, мы не знаем достоверно, что на самом деле нравится людям в нашем продукте и как они собираются его использовать, потому что у людей в голове свои тараканы и люди постоянно меняют свое мнение. Нужно преподнести им какой-либо вариант как можно раньше, чтобы у них была возможность сказать 'да', 'нет' или 'почти'. На протяжении нескольких месяцев вы постоянно разочаровываете заказчиков ради того, чтобы в конечном итоге сделать их счастливыми».

Делите все на части — пусть даже со стороны это напоминает хаос

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

Иногда вы будете получать примерно такие указания: «А добавьте-ка сюда интернет-магазин». И здесь возникает целый ряд вопросов. Насколько объемна такая задача? Какие операции будут выполняться в результате ее решения? Как все это должно выглядеть? Как будет использоваться? Задайте соответствующие вопросы, а затем разбейте ответы на более мелкие составляющие. В том-то и состоит мощь хаоса. Со стороны кажется, что ничего не происходит (в силу большого числа составляющих) , хотя сделать предстоит очень много, но группы специалистов различного профиля обладают всеми компетенциями, необходимыми для выполнения этой работы.

Акцентируйте внимание на новых возможностях, а не на скорости. Скорость придет

Еще одно частое заблуждение заключается в том, что agile-методология способствует ускорению работы команды. В какой-то степени это действительно так, но суть в другом. Команда разработчиков полнее реализует свои возможности, выдавая жизнеспособный продукт, а это уже приводит к увеличению скорости.

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

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

Будьте готовы к вечному совершенствованию

Как ответить на непременный вопрос: «Когда проект будет завершен?» Ответ очень прост – никогда. В этом и состоит вечное постоянство, особенно в мире программного обеспечения: за словом «завершен» скрывается весьма серьезная неопределенность, ведь постоянные доработки, обновления, исправления ошибок и функциональные изменения, дополнения и изъятия тех или иных функций представляют собой бесконечный процесс. «Проект окончательно завершен, когда последний пользователь удалит последнюю копию программы со своей машины, – заметил Оттингер. – В процессе постоянного совершенствования нельзя вести речь о каком-то завершении. Иначе ваш программный продукт просто устареет и окажется неконкурентоспособным».

Учитывайте эмпирический характер скорых методов

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

Почти 15 лет назад был представлен Agile Manifesto, в котором в качестве альтернативы традиционному управлению проектами создания программных систем предлагалась радикально измененная методология. Согласно принципам скорой (agile) разработки, требования к проекту и решения менялись посредством организации в цикле разработки взаимодействия, при котором все задачи разбиваются на небольшие составляющие. Такая методология помогает бизнесу управлять непредсказуемостью и требует для успешного решения задач изменения менталитета участников проекта.

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

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

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

Для начала имеет смысл проанализировать уже сложившуюся культуру разработки продуктов и управления проектами. Если организация демонстрирует реальные успехи, используя традиционную каскадную (waterfall) модель, наверное, стоит ее и придерживаться: определять цель, формировать команду, формулировать требования, проектировать решение, разрабатывать программный код, тестировать его и затем приступать к развертыванию созданного программного обеспечения в производственной среде. Другими словами, если жизненный цикл разработки систем в вашей организации отлажен и дает ожидаемые результаты, то никаких изменений вносить не надо!

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

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

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

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

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

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

• Фиксация выделяемого времени и ресурсных рамок проекта. Это ограничение лишает команду гибкости и дает бизнесу то, что он хочет, а не то, что ему нужно. При каскадной модели менеджеры проектов чувствуют себя достаточно комфортно, направляя запросы на изменения при необходимости скорректировать конкретные часы и задачи. При гибком проектировании в случае изменений разработчики постоянно добавляют новые элементы в портфель заказов (наборы требований), не меняя при этом границы проекта и расписание. И хотя требования при скорой разработке могут меняться, сроки всегда остаются теми же самыми.
• Определение сроков для всех итераций и задач заранее. Желание у начинающих менеджеров проектов, придерживающихся скорой методологии, заранее спланировать все требования, задачи и тексты для каждого спринта (так приверженцы скорой методологии называют итерации разработки) является вполне естественным. Не поддавайтесь соблазну! Попытки составить расписание заранее мешают самоорганизации команды и поиску оптимальных темпов, формирует нереальные ожидания в части сроков.
• Навязывание единых темпов разработки всем командам. Каждая команда придерживается собственных темпов, использует собственные методы преодоления трудностей и решает задачи с присущей ей скоростью. По мере вхождения в проект темпы возрастают, и менеджерам не стоит пытаться сравнивать скорость, с которой работают разные команды. Позвольте людям обучаться и усваивать новое в своем темпе (разумеется, под контролем куратора).
• Ощущение потери контроля. Если переход к скорой разработке осуществляется правильно и в нужных масштабах, руководители проектов и программ лучше понимают ежедневный ход работ, точно знают, что еще осталось сделать, и находятся в курсе всех пробуксовок.
• Отказ от привлечения специалистов по тестированию в процессе планирования и реализации спринтов. Закладывая в планы проверку качества, вы формируете направления для тест-планов и определяете, что понимается под «правильной работой» программы. Это требует от организации привлекать специалистов по тестированию значительно раньше, что само по себе уже становится отходом от каскадной методологии, при которой тестирование выполняется в конце. Теоретически привлечение специалистов по тестированию — идея хорошая, но на практике реализовать ее очень сложно, поскольку в каскадных проектах тестирование и проверка качества закладываются в бюджет (с выделением соответствующих ресурсов) ближе к концу проекта. Прежде чем приступать к сложным дискуссиям о распределении ресурсов, убедитесь в том, что ваши команды и руководители направления тестирования понимают важность перехода к скорой разработке!

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

Отдельного упоминания требует фактор качества. По данным компании Standish Group, организации, придерживающиеся скорой разработки, сообщают о повышении качества в среднем на 63%. Те, кто предпочитает устранять дефекты в процессе создания правильного продукта, вместо того чтобы проектировать то, что может не совпадать с желаниями заказчика, привносят в бизнес дополнительную ценность. А по мере улучшения качества и создания ценностей команды разработчиков обеспечивают полную прозрачность своих действий и укрепляют диалог между бизнесом и ИТ-подразделениями.

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

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

Джек Уолсер — менеджер компании AIM Consulting по обслуживанию клиентов, более 17 лет руководит работами, связанными с обеспечением непрерывных улучшений, разработкой программного обеспечения и реализацией проектов по трансформации стратегии.

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

Однако растет и популярность альтернативного подхода, связанного с использованием средств быстрой разработки. Особенно это касается разработчиков мобильных приложений — для них Agile-методики — единственная возможность не дать обойти себя многочисленным конкурентам.

Этот дуализм отметил Андрей Кутуков, директор HP Software в России, представляя 22 июля стратегию своей компании в сфере управления ИТ.

Однако разработать — даже не полдела. Новые релизы надо протестировать на соответствие требованиям заказчика, «ресурсоемкость» (приложение, за полчаса «сажающее» батарею, вряд ли будет востребовано, независимо от своей функциональности), безопасность, а затем еще и развернуть на всех серверах.

Как полагает Артур Гиоев, технический директор российского HP Software, единственный выход для разработчиков — использовать методологию DevOps.

DevOps (от Development и Operations) — методология разработки программного обеспечения, появившаяся в 2009 году. Ее основная черта — тесное и постоянное взаимодействие специалистов по разработке, тестированию и внедрению. Все эти процессы идут не последовательно, как в классическом случае, а почти параллельно. Продукт создается непрерывно, в каждом новом релизе добавляется одна-две функции, постоянно тестируется и развертывается у заказчика или отгружается в магазины приложений.

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

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

HP, как крупный разработчик программного обеспечения, активно использует подход DevOps при разработке и выводе на рынок собственных продуктов; несмотря на то, что они достаточно «крупные», промежуточные релизы выходят каждую ночь. В компании готовы делиться этим подходом с клиентами.

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

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

В мире методология DevOps уже достаточно популярна, в России же она появилась недавно, и, считает Гиоев, вряд ли есть организация, которая может похвастаться тем, что полностью ее внедрила. Но довольно многие уже сделали шаги в этом направлении. Специалисты HP проводят среди потенциальных заказчиков просветительскую работу, определяют вместе со специалистами клиентов текущее положение вещей, находят проблемные зоны, создают «дорожные карты» на несколько лет вперед, поскольку внедрение методологии, как уже говорилось, процесс достаточно длительный.

Разумеется, в соответствии с идеей DevOps этот процесс разбит на стадии, в конце каждой из которых заказчику обещан определенный результат. «Иначе невозможно, — настаивает Гиоев, — судьба длительных проектов слабо предсказуема, бизнес требует быстрых результатов в нашем часто меняющемся мире». Вот почему обычно дорожная карта разбивается на четыре части. Первые результаты должны быть видны через три месяца — так называемые быстрые победы, следующая контрольная точка — полгода, потом год, а далее должны быть видны результаты стратегических инициатив. «Соответственно мы прописываем, какие продукты должны быть готовы к тому или иному сроку, какие процессы и методологии должны быть освоены. Дальше мы действуем в соответствии с картой, контролируем процессы».

Как особо отметил Гиоев, важно понимать: внедрение DevOps — процесс непрерывный и взаимоувязанный. Нельзя его бросать на полдороге и снова начинать, нельзя осуществлять лишь часть намеченного — иначе все придется потом переделывать. «Очень важна системность», — говорит он.

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