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

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

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

Гибкие методологии, особенно Scrum, которые, по мнению многих ИТ-менеджеров, являются синонимом  Agile, лучше всего подходят для основной задачи ИТ-специалистов: разработке новых приложений.

За исключением веб-сайта компании и мобильных приложений, одним из основных принципов ИТ является: «покупайте, когда можете, разрабатывайте, когда вам нужно». ИТ-лицензии составляют примерно 90 процентов всех новых функций в виде коммерческого программного обеспечения (COTS) и программного обеспечения в качестве услуги (SaaS), оставляя 10 процентов для программного обеспечения, разработанного собственными силами.

Scrum, Kanban, Lean Software Development и большинство других гибких методологий рассчитаны на 10 процентов, а не на 90 процентов. Кроме того, в типичном магазине около 70 процентов времени работы разработчиков идет на поддержание и расширение приложений, уже находящихся в производстве, и 30 процентов для внедрения новых.

Считайте:  Agile в основном полезен для 10 процентов из 30 процентов - другими словами, он обрабатывает огромные 3 процента от того, что требуется от команды приложений ИТ.

Ваш результат может отличаться. Посмотрите на свои собственные числа. Результат все равно будет небольшим, но так не должно быть.

Техническое обслуживание и усовершенствование по методологии Agile

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

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

Agile и COTS

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

Но вы также можете применять методы agile для COTS. Вам просто нужно учесть два важных момента.

Во-первых: Внедрение COTS, будь то локально или через программное обеспечение как услугу (SaaS), не просто похоже на разработку программного обеспечения с нуля, возможно, требуется настройка или несколько. Она отличается основательностью способов, которые делают Scrum и Kanban серьезно непригодными для работы.

Во-вторых, это то, о чем мы уже упоминали: есть и другие методологии agile, более гибкие, чем  Scrum и Kanban

App dev vs COTS: все начинается с данных

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

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

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

Когда ИТ реализует несколько пакетов COTS / SaaS, существующие базы данных усложняют работу, вместо того, чтобы облегчать. Каждый пакет поставляется со своей собственной базой данных, и когда разработчики программного обеспечения разрабатывают свои базы данных, они не принимают те, которые у вас уже есть, потому что они не могут. Они также не учитывают тех, которые уже были разработаны другими поставщиками, потому что почему они должны?

Поэтому, когда ИТ реализует пакет COTS, он должен отслеживать все существующие базы данных, в которых хранятся те же данные, которым управляет новое приложение, - не использовать его, а выяснить, как сохранить дублирующие данные синхронизированными.

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

Описание того, что должно делать программное обеспечение

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

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

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

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

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

Большая стоимость, отсутствие улучшения бизнеса, по своему же замыслу. Что?

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

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

Двухступенчатый COTS

Когда бизнес (а не ИТ) реализует преднамеренные изменения в бизнесе с помощью COTS, есть два этапа: усилить компетентность программного обеспечения и оптимизировать бизнес.

Вы можете справиться с первым этапом, используя малоизвестный гибкий вариант, называемый Conference Room Pilot (CRP). Он работает следующим образом:

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

Затем вы привлекаете нескольких бизнес-пользователей и некоторых гуру приложений и запираете дверь.

Что происходит за запертой дверью? Бизнес-пользователь берет операцию, пытается заставить ее работать с программным обеспечением так, как есть, и объясняет гуру: «Я не могу обработать эту операцию, потому что ...» Разработчик исправляет «потому что», и он переходит к следующей причине. Через некоторое время эти «потому что» становится все труднее найти. В процессе их взаимодействия отходит Этап 1 и возникает Этап 2.

Переход отмечен изменением разговора. Если на первом этапе бизнес-пользователи объяснили, почему они не могут обработать транзакцию, разговоры на этапе 2 звучат так: «Я мог бы обрабатывать эту транзакцию более легко, если бы программное обеспечение ...»

Вуаля!  Разговоры больше не о том, чтобы сделать программное обеспечение компетентнее. Речь идет о том, чтобы сделать процессы более эффективными - об оптимизации бизнеса.

Да, и, кстати, ваши разработчики не являются пассивными заказчиками в этом процессе. В любое время они могут сказать что-то вроде: «Это получится невыгодно и запутанно. Как насчет того, чтобы вместо этого реализовать такой вариант?»

Самая страшная тайна Agile

Agile имеет секрет более глубокий, чем бесполезный для большей части того, что делает ИТ: гибкая разработка - это все о доставке продукта. Независимо от того, будет ли это Scrum, Kanban, Lean или что-то еще, проект завершается, когда ИТ поставляет программный продукт.

Но независимо от того, используете ли вы Scrum для разработки программного обеспечения с нуля или пакета с использованием CRP, доставка продукта не совсем то, что нужно бизнесу. Если ПО не приносит изменения бизнесу, то в нем нет смысла.  Приложение - это рычаг, который может использовать бизнес для достижения желаемого изменения.

Вся вторая стадия CRP заключается в том, чтобы заставить бизнес работать по-другому и лучше. В нее закладывается преднамеренное изменение бизнеса.

С другой стороны, использование технологий Agile для разработки приложения связано с риском того, что изменение бизнеса станет проблемой “кого-то другого”, потому что все, что касается Scrum, Kanban и остальных, тщательно обрабатывается, чтобы сделать целью доставку продукта. Если бы это было не так, у нас не было бы владельцев продуктов, и пользовательские истории не были бы о том, что должно делать программное обеспечение.

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

Заключение

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

No Comments