Agile

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

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

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

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

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

Если жизненный цикл разработки систем в вашей организации отлажен и дает ожидаемые результаты, то никаких изменений вносить не надо!

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

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

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

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

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

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

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

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

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

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

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

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

– Jack Walser. Agile development: Adopt gradually or dive in? Network World (US). 01/22/2015

Хотя принципы скорой (agile) разработки изначально были предложены создателями программного обеспечения, сегодня они применимы практически в любой сфере. В их основе лежат сотрудничество, открытые коммуникации, доверие и независимость, эффективность и непрерывная выдача результатов. Все это способно сформировать долгосрочный позитивный эффект почти в каждой структурной части вашей организации. На прошедшей недавно в Вашингтоне конференции Agile Alliance 2015 старший консультант компании Industrial Logic Тим Оттингер изложил шесть принципов концепции скорой разработки, которые можно использовать фактически повсеместно.

Помните: иногда работа выглядит не так, как вы привыкли

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

«Работа заключается в том, чтобы думать, а не стучать по клавишам, – указал Оттингер. – Мозговые штурмы, обсуждение и даже простое пребывание вместе с членами команды – все это часть работы. Иногда самые удачные идеи и решения приходят в голову не во время многочасового написания кода, а во время прогулки. Нужно считать не время, в течение которого пальцы бьют по клавишам, а время, когда остаются в игре».

Формируйте ценности как можно раньше и как можно чаще

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

«Временны’е ограничения скорого подхода снижают вероятность аварий, ошибок, выбора неверного направления и прочих проблем, – подчеркнул Оттингер. – Рамки сужаются. Будучи разработчиками, мы не знаем достоверно, что на самом деле нравится людям в нашем продукте и как они собираются его использовать, потому что у людей в голове свои тараканы и люди постоянно меняют свое мнение. Нужно преподнести им какой-либо вариант как можно раньше, чтобы у них была возможность сказать “да”, “нет” или “почти”. На протяжении нескольких месяцев вы постоянно разочаровываете заказчиков ради того, чтобы в конечном итоге сделать их счастливыми».

Делите все на части – пусть даже со стороны это напоминает хаос

Если ваша команда завалена несметным количеством объемных проектов, необходимо упорядочить их. Разделяйте работу на составные части, которые могут быть реализованы в рамках спринта. Повторяйте это до тех пор, пока все задачи не будут разбиты и распределены с учетом ресурсов каждой команды, с тем чтобы ими можно было управлять. Все это требует интенсивного предварительного планирования – нужно убедиться в том, что задачи бизнеса правильно определены и сформулированы.

Иногда вы будете получать примерно такие указания: «А добавьте-ка сюда интернет-магазин». И здесь возникает целый ряд вопросов. Насколько объемна такая задача? Какие операции будут выполняться в результате ее решения? Как все это должно выглядеть? Как будет использоваться? Задайте соответствующие вопросы, а затем разбейте ответы на более мелкие составляющие. В том-то и состоит мощь хаоса. Со стороны кажется, что ничего не происходит (в силу большого числа составляющих) , хотя сделать предстоит очень много, но группы специалистов различного профиля обладают всеми компетенциями, необходимыми для выполнения этой работы.

Акцентируйте внимание на новых возможностях, а не на скорости. Скорость придет

Еще одно частое заблуждение заключается в том, что agile-методология способствует ускорению работы команды. В какой-то степени это действительно так, но суть в другом. Команда разработчиков полнее реализует свои возможности, выдавая жизнеспособный продукт, а это уже приводит к увеличению скорости.

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

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

Будьте готовы к вечному совершенствованию

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

Учитывайте эмпирический характер скорых методов

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

– Sharon Florentine. 6 agile principles that apply to everything. CIO.

Scrum: результат в условиях неопределенности

Гибкие (agile) методики реализации ИТ-проектов — иногда, в зависимости от контекста, встречается вариант перевода «скорые» — получают все большее распространение. 84% ИТ-департаментов, опрошенных VersionOne, ответили утвердительно на вопрос, применяют ли они гибкие методики разработки. Среди них 54% заявили об использовании методики Scrum. Более того, компетенции в Scrum, наряду с технологиями in-memory и предсказательной аналитикой, входят в рейтинг наиболее востребованных ИТ-навыков, составленный Foote Partners.

Гибкие методики соответствуют изменившимся требованиям рынка: устранить риски и увеличить скорость разработки, снизить вероятность провала проекта. По данным The Standish Group, число неудач в Scrum-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше.

Гибкие подходы избавляют от многих рисков благодаря более активному взаимодействию команды разработчиков между собой и с заказчиками. За двухнедельные интервалы разработок — «спринты» — гораздо проще создать продукт, отвечающий базовым требованиям пользователей, и затем дорабатывать его на основе полученной обратной связи, чем ждать реализации крупного функционала, который в итоге не будет соответствовать бизнес-требованиям.

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

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

С учетом роста фактора мобильности компаниям придется переходить на гибкие методики разработки приложений. В Gartner утверждают, что традиционные методы, используемые для создания корпоративных систем, не будут эффективными в случае создания мобильных приложений. Мобильная разработка имеет ряд специфических особенностей — например, потребность в многоплатформенности приложений. Кроме того, пользователи часто не могут четко описать, что мобильное приложение должно делать. Традиционная работа системных аналитиков по сбору требований успехом не заканчивается. С этой точки зрения правильнее идти небольшими шагами.

Как отметил Михаил Петров, заместитель директора департамента проектов по информатизации Министерства связи и массовых коммуникаций РФ, в рамках дискуссии «Мы за скрам!» на портале Global CIO, любая методология имеет область адекватного применения. «Scrum подразумевает намного большую квалификацию исполнителя — как с точки зрения управления объемом и ресурсами, бюджетом, рисками, так и в плане управления ожиданиями заказчика, требует вовлечения заказчика в процесс и создания определенного партнерства», — подчеркивает он. «Классически» воспитанный ИТ-менеджер к такому не привык, но для некоторых проектов (когда делать надо в четко определенный срок, но что — до конца не понятно) такая методология становится единственным выходом. Иногда традиционный подход дает вполне приемлемые результаты, но в ситуации, когда среда меняется, Scrum будет все более и более востребован.

«Традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Эти требования меняются настолько динамично, что то видение, которое было в начале проекта, становится кардинально иным к его концу», — констатирует Тагир Яппаров, председатель совета директоров «АйТи». «Водопад» при таком положении дел дает плохие результаты, ведет к неудачам или превышению по бюджетам и срокам. Поэтому начали активно применяться более динамичные методологии, и Scrum стал элементом крупных проектов. Даже у SAP появились методологические изменения, которые отражают видение таких подходов.

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

«В 90-е годы я сам использовал методологию Scrum — правда, не зная об этом: прямой контакт с заказчиком, реализация с его слов, короткие циклы, постоянные презентации», — вспоминает Александр Огнивцев, руководитель управления сервисной поддержки «АльфаСтрахования». Разница в том, что в те годы заказчик, как правило, точно знал, чего хочет, но не знал, что это можно реализовать через ИТ. Теперь заказчик точно знает, что с помощью ИТ реализовать можно все, но не знает, чего хочет. Ситуация неопределенности воспроизвелась: теперь на новом витке и в иной ситуации, — и конечно, гибкие технологии становятся востребованными.

«Мне кажется, что на открытом конкурентном рынке заказчики вряд ли примут решение в пользу Scrum, потому что основной его минус — неясные результаты за непонятный бюджет», — признает Георгий Давыдов, архитектор интеграционных решений R-Style Softlab. — Покупатель, понятное дело, предпочтет определенные сроки и цифры. Из-за этого приходилось даже скрывать свой «внутренний» Scrum от заказчика, хотя сейчас его элементы используются даже на «водопадных» проектах».

Преимущества этой методики управления прямо проистекают из ситуаций, когда ее выгодно применить. Например, заказчик не знает, что ему нужно; говоря более обобщенно — нет технического задания, что позволяет вообще исключить такой обязательный для «водопада» этап. «С одной стороны, экономия налицо, с другой стороны, привязка к партнеру становится катастрофической, да и сам исполнитель «подсаживается» на ключевых сотрудников. Как вы думаете, полетел бы Гагарин в космос, если бы ракету строили по Scrum?» — задается вопросом Давыдов. Другими примерами могут быть ситуации, когда по каким-либо причинам не получается оценить сроки и бюджет проекта, нужны быстрые результаты или когда исполнитель, не зная инструментов, изучает технику и предметную область на ходу. Наконец, возможен вариант, когда команда устала от однообразия и нужно привнести драйва, а текущая эффективность никого не устраивает.

«Как человек, имеющий команды разработчиков в штате и работающий с аутсорсерами, согласен, что по Scrum хорошо работать, когда обладаешь штатной командой, а запросы от подразделений меняются по два раза на день», — говорит Дмитрий Тепляков, ИТ-директор компании «Донбасс Арена». Тогда работа спринтами имеет смысл: заказчику сразу выдается небольшой работающий кусок, а он корректирует направление работ. Если заказчику результат не нравится — потеря времени на переделки небольшая.

Но ситуация совершенно иная, когда крупный проект заказывается у аутсорсера. «Как заказчика меня совершенно не устраивает работа по принципу открытого бюджета. Точнее, меня-то она, может, и устроит, но вот финансовый директор будет против», — отмечает Тепляков. В итоге нужно получить хотя бы рамочное понимание затрат, а это по Scrum сделать практически невозможно. А потому приходится идти по стандартной методике, составляя детальное техническое задание и создавая прототип, — по сути классический «водопад».

«Противопоставление фиксированной для реализации задачи («водопад») и нефиксированной (scrum) в корне неверно», — уверен Алексей Лапшин, руководитель проектного сервиса «АйТи». Ни та ни другая методология не отвечают на вопрос, что будет реализовано, а отвечают на вопрос, как будет реализовано и кто для этого нужен. Это как с геометриями Лобачевского и Евклида — вторая является предельным случаем первой. Если установить продолжительность «спринта» во время, отведенное на весь проект, то Scrum превратится в «водопад».

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

«Сама методика «водопада» никаким образом не препятствует внедрению гибких методов разработки», — согласен Борис Позин, технический директор «ЕС-Лизинг». Скорее, ему препятствует модель Fixed Price, которая применяется в большинстве случаев, и в госзаказах прежде всего. Таким образом, не надо путать экономику, менеджмент и технику.

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