Темные стороны Agile

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

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

Один из главных принципов ИТ формулируется так: покупай, когда можешь, создавай, когда нужно. ИТ-службы лицензируют около 90% всего нового функционала в виде готового коммерческого программного обеспечения или программного обеспечения, предоставляемого в виде сервиса (software as a service, SaaS), оставляя на разработку его собственными силами всего 10%.

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

Проведем несложные подсчеты. Agile-проектирование оказывается полезным лишь для 10% из 30% – то есть для 3% приложений, которыми занимаются команды разработчиков.

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

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

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

Применять agile-методологии при внедрении «коробочных» продуктов (Commercial Off-The-Shelf, COTS) уже не так просто, как в ходе поддержки и улучшений. Впрочем, никто этого и не ждет: построение крупных систем – не такой простой процесс, как управление поддержкой и улучшениями.

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

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

Проектировать...