Rambler's Top100
Статьи
Валерий АНДРЕЕВ   08 июня 2018

Agile – значит «быстрый»

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

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

Методами Agile сегодня работают команды, руководителями и инвесторами которых являются люди, «зараженные» какой-либо идеей и готовые воплощать ее рискованным методом проб и ошибок. Стремясь опередить конкурентов, быстро вывести на рынок продукты и услуги с новыми свойствами, заказчик «стиля Agile» идет на эксперимент: он постоянно двигается вперед – на ощупь, мелкими шагами, не всегда имея детальное представление о конечном результате. Но таким образом он получает выигрыш во времени: пока «люди из oldschool» размышляют над постановкой задачи и разрабатывают ТЗ, «люди Agile» успевают в общих чертах реализовать будущее решение, выйти на полумакет, создать и даже предоставить пользователям отдельные функциональные блоки, которые сразу же начинают прирастать сервисами (как, например, в проектах разработки корпоративных порталов).

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

В опытную эксплуатацию – за три месяца

«ИВК» время от времени применяет Agile в своих проектах. Впервые мы использовали этот подход в 2008 году, хотя тогда и не догадывались, что действуем в рамках какой-то продвинутой концепции. Обстоятельства сложились так, что перед нами встала задача в более чем сжатые сроки разработать сложную информационную систему для очень крупного и серьезного ведомства. Фактически -- автоматизировать офис размером со всю страну. Новое руководство испытало настоящий шок, выяснив, что вся автоматизация ведомства представляет собой переписку по электронной почте, и спешило исправить ситуацию. Всего за три месяца мы изучили отечественные и европейские стандарты документооборота, описали структуру данных, разработали функционал, отточили интерфейс и запустили систему в опытную эксплуатацию. Никакого ТЗ изначально не было, лишь общее видение целей. Разработчики «ИВК» и сотрудники заказчика сообща шли опытным путем: конкретизировали детали, быстро воплощали их в функционале, пробовали, изучали ошибки, исправляли, выпускали новые версии, снова отрабатывали... Сначала пилотной зоной была охвачена лишь вертикаль коммуникаций службы заказчика, затем ее расширили на другие подразделения, одновременно продолжая создавать и отрабатывать новый функционал. В результате на свет появилась СЭД «ИВК Бюрократ».

Мы не смогли бы выполнить этот проект, если бы не опирались на собственную разработку – платформу «ИВК Юпитер» класса middleware. Она использовалась в разных проектах как гарантированная транспортная платформа. В «ИВК Юпитер» реализован собственный протокол информационного обмена, который гарантированно передает данные по различного рода физическим каналам связи, предоставляет средства контроля доступа и работы с пользователями (авторизация, хранение учетных записей, работа с паролями и т.п.). И, что крайне важно, платформа обладает развитым интерфейсом прикладного программирования, который позволяет реализовать работу с хранилищем, с всевозможными протоколами передачи, с данными пользователей и т.д. В ходе проекта мы фактически «научили» платформу работать с данными, сгруппированными для описания документа.

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

Сегодня «ИВК» реализует еще один большой проект по методике Agile. Программный продукт для контроля работы ЦОДа создается на платформе мирового масштаба – на OpenSource. Ряд фрагментов функционала строится на решениях открытых проектов.

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

Agile не панацея

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

Другой распространенный риск – сотрудничество заказчиков с командами, не имеющими знаний и опыта работы с платформенными решениями и организации процессов согласно методике Agile. Тогда разработчик набирается опыта методом проб и ошибок, ставя своего рода эксперимент на заказчике. Избежать этого риска позволяет сотрудничество с разработчиком, который накопил опыт работы с соответствующим платформенным решением (портальной платформой, СЭД, ERP, CRM), на основе которого он может реализовать любой необходимый заказчику сервис -- от традиционного до экзотического. В качестве платформы может выступать и репозиторий, на основе которого собираются разнообразные программные пакеты. Кроме того, опытный и надежный разработчик должен иметь команду, которая хорошо освоила стиль Agile. Если же у разработчика нет подобного бэкграунда, риски резко возрастают.

А вот при формировании самой платформы Agile категорически не применим. Дело в том, что «быстрые забеги» можно совершать, уже базируясь на важном знании, на некоем программном фундаменте. Поэтому сами платформы формируются только планово, медленно. Например, ни одна из версий Linux не формировалась и не будет формироваться в концепции «сумасшедшего Agile за три недели». Иначе у разработчиков, которые используют платформу для создания своих решений, начнутся проблемы: невозможно создавать надстройку, когда фундамент постоянно изменяется. Кстати, и при разработке платформы «ИВК Юпитер» Agile не применялся. Этот продукт формировался планово и тщательно, в рамках работы группы разработчиков над различными проектами в течение нескольких лет, а не месяцев.

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

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

Валерий Андреев, заместитель директора по науке и развитию, «ИВК»
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!