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

В Gartner сформулировали 10 рекомендаций для ИТ-руководителей, желающих испробовать возможности скорой разработки.

  • Agile – это не одна методика, а набор подходов к разработке ПО. Опытная организация может использовать несколько из них, но начинающим лучше сфокусироваться на одном.
  • Agile – это не конструктор, позволяющий собрать нужный подход из нескольких методов. Каждый компонент каждой методологии крайне важен для ее успеха.
  • Успех аgile требует тесного взаимодействия ИТ с бизнесом. Их преимущества просто не могут быть реализованы без вовлечения всех заинтересованных сторон.
  • Начинайте постепенно. Опытные практики аgile могут реализовывать очень крупные и сложные проекты, но на приобретение необходимого опыта уйдет много лет.
  • Agile требует непрерывного обучения внутри организации. Сотрудники постоянно ищут возможности улучшать качество и эффективность.
  • Agile – это в первую очередь сбалансированные команды, включающие разработчиков и специалистов по контролю качества. Их оптимальной численностью считается семь плюс-минус два человека.
  • Документирование – ключевой для минимизации рисков процесс.
  • Agile в отношениях с аутсорсерами, как показал опыт многих компаний, требует особого внимания.
  • Влияние аgile распространяется дальше, чем команды разработки. Бизнес-пользователи являются ключевыми участниками проекта, непосредственно влияющими на его успех.
  • Другие методы разработки по-прежнему имеют право на существование. Agile не должна быть единственной используемой методологией. В каких-то случаях эта методика хроша, а в каких-то – не очень.

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

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

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

«У нас могут быть и один, и несколько владельцев, но роль лидера обычно одна в каждый момент времени – идет согласование лидерства. А еще в некоторых случаях владельцем бывает «наш» человек с согласия заказчика», – делится опытом Татьяна Орлова, заместитель председателя экспертного совета itSMF. Часто грамотный ИТ-специалист лучше заказчика понимает ситуацию, владея знаниями в профильной области и понимая возможности ИТ. Таким образом, хорошо работает совмещение в одной голове ролей аналитика и архитектора. Сложно, но очень эффективно.

«Попробуйте применить скрам при работах по матрице требований к проекту. Вам понравится результат», – рекомендует Игорь Столяренко, ИТ-директор лаборатории «Образование для Новой Эры».

По мнению Николая Вяткина, заместителя ИТ-директора сети гипермаркетов «Лента», скорые методики имеют очень ограниченную область применения. «Мои аргументы строятся на опыте работы как на стороне разработчика, так и на стороне заказчика. У нас в компании параллельно ведутся более 20 проектов, из них только в нескольких применяется модель скорых методологий управления проектами», – говорит Вяткин. Сила скорых методик – в быстрой и гибкой разработке нового, еще не существующего продукта в условиях постоянно изменяющихся требований и приоритетов. При внедрениях же существующих платформ они не эффективны. Можно использовать смешанные подходы (например, соединив скрам с CMMI), но это уже нельзя назвать скорой методологией.