Похоже, гибкое проектирование становится уже вчерашним днем. А как же передовые компании? Они уже перешли на DevOps. Более того, многие разработчики приложений не только не взяли на вооружение agile-технологии, но даже не имели таких намерений.
Все перечисленное может казаться странным, пока вы не познакомитесь поближе с реальными потребностями команд разработчиков. И тогда окажется, что методологии гибкого проектирования очень мало отвечают их целям.
Agile-методологии (в особенности Scrum, которую многие ИТ-менеджеры считают синонимом гибкого проектирования) лучше всего подходят для разработки новых приложений, а как раз в этом-то ИТ-организации нуждаются менее всего.
Один из главных принципов ИТ формулируется так: покупай, когда можешь, создавай, когда нужно. ИТ-службы лицензируют около 90% всего нового функционала в виде готового коммерческого программного обеспечения (commercial off-the-shelf software, COTS) или программного обеспечения, предоставляемого в виде сервиса (software as a service, SaaS), оставляя на разработку его собственными силами всего 10%.
Scrum, Kanban, Lean Software Development и другие agile-методологии предназначены для создания всего 10% программного обеспечения. При этом 70% своего времени типичный разработчик тратит на поддержку и расширение функционала уже эксплуатируемых приложений и только 30% остается у него для создания новых.
Проведем несложные подсчеты. Agile-проектирование оказывается полезным лишь для 10 из 30% – то есть для 3% приложений, которыми занимаются команды разработчиков.
Конечно, в разных ситуациях доля эта может варьироваться. Но в любом случае процент весьма небольшой.
Agile-путь поддержки и улучшений
Давайте начнем с простого: запросов на обслуживание и улучшения, которые составляют значительную часть повседневной работы ИТ-службы.
Не нужно сильно всматриваться в очередь, чтобы заметить, насколько все здесь напоминает agile-методологию. Добавляем владельца продукта (человека, отвечающего за его разработку) и начинаем формулировать запросы, представленные в виде пользовательских историй (изложенных на бизнес-языке требований к разрабатываемой системе). Мы проделали это за минуту. Применяем Kanban: владелец продукта определяет приоритеты, а разработчик, выполнив очередное задание с пользовательской историей, переходит к следующему. Накладные расходы минимальны, а работа выполнена.
Agile-разработка COTS
Применять agile-методологии при реализации проектов COTS уже не так просто, как в ходе поддержки и улучшений. Впрочем, никто этого и не ждет: построение крупных систем – не такой простой процесс, как управление поддержкой и улучшениями.
Однако agile-технологии можно применять и к COTS. Нужно только учитывать два важных момента.
Первый: внедрение COTS, как на своей территории, так и в виде SaaS, не предполагает разработку программного обеспечения с нуля, а ограничивается одной-двумя настройками. А потому Scrum и Kanban фактически непригодны для решения таких задач.
Второй момент: помимо Scrum и Kanban существуют и другие agile-методологии.
Разработка приложений против внедрения COTS: все начинается с данных
Приступая к разработке программного обеспечения, ИТ-команда должна понять, какие требования предъявляются к нему со стороны бизнеса. Уяснив эти требования, не нужно сразу приступать к разработке ПО. Начать следует с проектирования структур данных.
Проектировать структуры данных не нужно лишь в тех случаях, когда база данных уже существует и отвечает всем потребностям нового приложения.
При внедрении сразу нескольких пакетов COTS/SaaS существующие базы данных только осложняют, а не упрощают работу. Каждый пакет поставляется со своей собственной базой данных, а при проектировании своих баз данных поставщики совершенно не учитывают те, что у вас уже имеются. У них просто нет соответствующей информации. Они не обращают никакого внимания и на базы данных других поставщиков.
Внедряя пакет COTS, ИТ-служба должна отслеживать все существующие базы данных, в которых находится та же информация, что нужна новому приложению. И делается это не ради извлечения дополнительных выгод из уже существующих баз данных, а для синхронизации пересекающихся данных.
Если вести речь об управлении данными, внутренняя разработка очень сильно отличается от внедрения готовых пакетов.
Что должно делать программное обеспечение
Имея на руках данные, разработчики должны описать, чего хочет от программного обеспечения бизнес. Большинство гибких вариантов предполагают использование для этих целей «пользовательских историй» – утверждений следующего вида: «Будучи <тип пользователя>, я хочу <цель> в силу <разумная причина>». Например, «Будучи специалистом по телефонному маркетингу, я хочу накапливать и хранить информацию о клиентских домохозяйствах, с тем чтобы звонить только тем людям, которые, возможно, захотят приобрести продаваемый мною продукт».
Имейте в виду: внедряя систему CRM, вы отнимаете у всех время и раздражаете бизнес-менеджеров, настаивая на получении от них соответствующей информации. Если же во внедряемой системе CRM информация обо всех типах клиентов не хранится, никакой пользы от такой системы не будет.
При внедрении ПО COTS или SaaS обычно возникает спор о том, следует ли внедрять его «в том виде, в каком оно есть», или же полностью адаптировать к бизнес-процессам компании. Но спорить тут совершенно не о чем.
Программное обеспечение поставляется с явными или подразумеваемыми версиями бизнес-процессов, которые в одних случаях существенно превосходят те, что используются в настоящее время на предприятии. А в других случаях – нет.
Те, кто ратует за адаптацию (потому что ИТ должны сделать всех «внутренних клиентов» счастливыми), лоббируют, по сути, большие денежные затраты на ПО, в котором будут реализованы уже имеющиеся бизнес-процессы.
Огромные расходы и никаких улучшений с точки зрения бизнеса. Зачем?
При внедрении системы без изменений бизнес-процессы, естественно, будут отличаться, но не потому, что так сложилось у разработчиков, а потому, что так должно быть.
Однако если ваша компания является лучшей в своем бизнесе, то, внедряя проект без изменений, вы выбираете в качестве стратегии преднамеренное ухудшение бизнеса.
Когда ИТ-служба и бизнес-подразделения начинают спорить о том, следует ли внедрять проект без изменений или же полностью адаптировать его, ничего хорошего в этом нет. И такой спор следует сразу прекратить.
Двухэтапный проект COTS
Когда бизнес, а не ИТ-подразделение, внедряя COTS, вносит в свою деятельность намеренные коррективы, усилия разбиваются на два этапа: сделать программное обеспечение приемлемым для себя и оптимизировать бизнес.
Первым этапом можно управлять с помощью малоизвестной agile-методологии Conference Room Pilot (CRP). Вот как это работает.
Сначала основные данные (клиентские данные, данные о продуктах и пр.) загружаются в базу данных нового пакета. Затем руководитель проекта в большом зале размещает множество демонстрационных досок, больших мониторов и других интересных вещей. Далее в новый пакет заносится масса деловых транзакций, с тем чтобы обеспечить его соответствие потребностям бизнеса.
Транзакции эти могут быть результатом тщательно разработанного плана тестирования. Или реальными транзакциями за прошлый месяц и более ранние периоды. Любой вариант работает хорошо.
Затем в зале размещаем несколько бизнес-пользователей и ряд гуру в области приложений.
Вот что происходит дальше. Бизнес-пользователь берет транзакцию, пытается провести ее с помощью программного обеспечения и объясняет знатоку приложений, что не может обработать ее, потому что… Разработчик устраняет названную причину и переходит к следующей. Со временем находить причины становится все труднее. Происходит постепенный переход от первого этапа ко второму.
В процессе перехода тон разговора меняется. Если на первом этапе бизнес-пользователь объяснял, почему не может выполнить транзакцию, то на втором говорит, что ее можно было бы выполнить проще, если бы программное обеспечение умело…
Вуаля! Разговор идет уже не о том, чтобы программное обеспечение могло выполнять возложенные на него задачи, а о повышении эффективности процессов – об оптимизации бизнеса.
И кстати, ваши разработчики в ходе этого процесса уже не пассивные исполнители заказа. В любое время они могут возразить, что менять программное обеспечение предлагаемым способом слишком неудобно и дорого. А что, если пойти вот таким путем?
Темные стороны agile-проектирования
У agile-проектирования есть недостатки и похуже, чем бесполезность для решения большинства ИТ-задач. Гибкое проектирование направлено на доставку продукта. Независимо от того, идет ли речь о Scrum, Kanban, Lean или о чем-то еще, проект считается завершенным после поставки программного продукта.
Но и при использовании Scrum для разработки ПО с нуля, и при применении CRP к готовому пакету конечная цель состоит не в доставке продукта, а во внутренних изменениях бизнеса. Приложение – это всего лишь инструмент, с помощью которого бизнес может осуществлять желаемые преобразования.
Весь второй этап CRP направлен на то, чтобы заставить бизнес работать лучше. Внутренние изменения бизнеса заложены в нем изначально.
С другой стороны, применение технологий agile-разработки приложений сопряжено с риском того, что изменения бизнеса останутся проблемой кого-то другого, поскольку цели Scrum, Kanban и прочего ограничиваются доставкой продукта.
Нужны технологии, дающие возможность описывать, как сделать процесс лучше, превращать это описание в пользовательские истории и добавлять в список новые задачи, позволяющие менять бизнес.
А еще лучше, чтобы эти технологии помогали последовательно и постепенно описывать улучшения бизнеса в различных областях, итерационно вносить соответствующие изменения в приложения и воплощать тем самым в жизнь идеи совершенствования бизнеса.
***
Возможно, темные стороны agile-проектирования пока не слишком актуальны. Но полностью игнорировать их – значит растрачивать ресурсы, заниматься бессмысленными спорами и объявлять успешными проекты, которые на самом деле оборачиваются провалами, как только кто-нибудь поинтересуется, стала ли компания лучше в результате их внедрения.
– Bob Lewis. Agile’s dark secret? IT has little need for the usual methodologies. CIO. MAR 30, 2018
