Почти 15 лет назад был представлен Agile Manifesto, в котором в качестве альтернативы традиционному управлению проектами создания программных систем предлагалась радикально измененная методология. Согласно принципам скорой (agile) разработки, требования к проекту и решения менялись посредством организации в цикле разработки взаимодействия, при котором все задачи разбиваются на небольшие составляющие. Такая методология помогает бизнесу управлять непредсказуемостью и требует для успешного решения задач изменения менталитета участников проекта.

Скорые методы служат для управления взаимодействием, прозрачностью и качеством на протяжении всего жизненного цикла продукта и разработки программного обеспечения, но не всегда бывают правильным выбором для любой организации. Авторы манифеста подчеркивают: наряду с изучением того, что представляет собой скорая разработка, немалую ценность составляет и понимание того, чем она не является.

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

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

Для начала имеет смысл проанализировать уже сложившуюся культуру разработки продуктов и управления проектами. Если организация демонстрирует реальные успехи, используя традиционную каскадную (waterfall) модель, наверное, стоит ее и придерживаться: определять цель, формировать команду, формулировать требования, проектировать решение, разрабатывать программный код, тестировать его и затем приступать к развертыванию созданного программного обеспечения в производственной среде. Другими словами, если жизненный цикл разработки систем в вашей организации отлажен и дает ожидаемые результаты, то никаких изменений вносить не надо!

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

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

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

  1. Взаимодействие между командой разработчиков и клиентом становится заметно эффективнее, нежели в ходе очень долгого процесса общения на языке контрактов и требований.
  2. Упор делается не на процессы и инструменты, а на вовлечение конкретных лиц и организацию взаимодействия между ними.

Еще одним фактором при принятии решения является зрелость процессов в вашей организации. Если на предприятии внедрено процессное управление, а вы подумываете о переходе к методологии скорой разработки программного обеспечения, необходимо понять, как это будет осуществляться на практике. К примеру, переход от каскадной процессной модели к скорым методам подразумевает отказ от устойчивых процессов и «ослабление контроля", а многим менеджерам проектов, привыкших управлять процессами, такое трудно будет переварить. Для того чтобы люди поняли преимущества постепенного или одномоментного внедрения методологии скорой разработки, необходимо внести серьезные изменения в систему управления и организовать дополнительное консультирование.

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

  • Фиксация выделяемого времени и ресурсных рамок проекта. Это ограничение лишает команду гибкости и дает бизнесу то, что он хочет, а не то, что ему нужно. При каскадной модели менеджеры проектов чувствуют себя достаточно комфортно, направляя запросы на изменения при необходимости скорректировать конкретные часы и задачи. При гибком проектировании в случае изменений разработчики постоянно добавляют новые элементы в портфель заказов (наборы требований), не меняя при этом границы проекта и расписание. И хотя требования при скорой разработке могут меняться, сроки всегда остаются теми же самыми.
  • Определение сроков для всех итераций и задач заранее. Желание у начинающих менеджеров проектов, придерживающихся скорой методологии, заранее спланировать все требования, задачи и тексты для каждого спринта (так приверженцы скорой методологии называют итерации разработки) является вполне естественным. Не поддавайтесь соблазну! Попытки составить расписание заранее мешают самоорганизации команды и поиску оптимальных темпов, формирует нереальные ожидания в части сроков.
  • Навязывание единых темпов разработки всем командам. Каждая команда придерживается собственных темпов, использует собственные методы преодоления трудностей и решает задачи с присущей ей скоростью. По мере вхождения в проект темпы возрастают, и менеджерам не стоит пытаться сравнивать скорость, с которой работают разные команды. Позвольте людям обучаться и усваивать новое в своем темпе (разумеется, под контролем куратора).
  • Ощущение потери контроля. Если переход к скорой разработке осуществляется правильно и в нужных масштабах, руководители проектов и программ лучше понимают ежедневный ход работ, точно знают, что еще осталось сделать, и находятся в курсе всех пробуксовок.
  • Отказ от привлечения специалистов по тестированию в процессе планирования и реализации спринтов. Закладывая в планы проверку качества, вы формируете направления для тест-планов и определяете, что понимается под «правильной работой» программы. Это требует от организации привлекать специалистов по тестированию значительно раньше, что само по себе уже становится отходом от каскадной методологии, при которой тестирование выполняется в конце. Теоретически привлечение специалистов по тестированию — идея хорошая, но на практике реализовать ее очень сложно, поскольку в каскадных проектах тестирование и проверка качества закладываются в бюджет (с выделением соответствующих ресурсов) ближе к концу проекта. Прежде чем приступать к сложным дискуссиям о распределении ресурсов, убедитесь в том, что ваши команды и руководители направления тестирования понимают важность перехода к скорой разработке!

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

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

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

Итак, прежде чем принять решение о постепенном или одномоментном переходе к скорой разработке, необходимо проанализировать свою корпоративную культуру и готовность к изменениям. Оцените стремление своей команды к повышению качества и получению более высокой отдачи. Насколько велико желание бизнеса ускорить вывод на рынок новых предложений и наращивать свои конкурентные преимущества? Проанализируйте текущее состояние вовлеченности (удовлетворенности) клиентов и сотрудников. Это поможет понять, что для вашей команды лучше — осуществить переход к скорой разработке (сразу либо постепенно) или же по-прежнему придерживаться каскадного подхода.

Джек Уолсер — менеджер компании AIM Consulting по обслуживанию клиентов, более 17 лет руководит работами, связанными с обеспечением непрерывных улучшений, разработкой программного обеспечения и реализацией проектов по трансформации стратегии.