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

Общая информация

Первоначально давайте разберёмся с техническими моментами. Что собой представляет Agile? Перевод (дословный) этого слова с английского языка - «живой, подвижный», немногим реже упоминается «гибкий». И кстати, это сокращение. Полное название этого подхода это Agile software development. Но поскольку это слишком долго, то и было решено сократить. И сейчас говорят просто Agile. Перевод как «гибкий» используется из-за того, что он в наибольшей мере соответствует реальной ситуации.

Что же сюда включено?

Продолжаем рассматривать, что такое Agile. Здесь хочется сконцентрировать внимание на том, что это гибкий подход, в основе которого лежит множество различных ХР, "Канбан", Lean). Для того чтобы лучше разобраться в теме, давайте проведём параллели. Допустим, что Agile-технологии - это процесс зарождения Вселенной. Конечный продукт - непосредственно сам существующий мир. А большой взрыв - это наиболее болезненная проблема, с которой только приходится встречаться, - изменение перечня требований к продукту. Обычно процессы создания подразумевают использование каскадной модели. В этом случае всё идёт последовательно и по этапам. Такой подход можно выразить кратко: вижу цель - иду к ней. И если меняются требования к конечному результату, то иногда приходится переделывать заново едва ли не всё. Что еще усложняет такую ситуацию, так это попытка сделать вид, что всё нормально, и нужно двигаться вперед.

И вот управления, призвана бороться со всем этим благодаря своей гибкости. Эта сборная "солянка" минимизирует различные риски посредством использования наборов принципов. Все они отражены в Agile-манифесте, выпущенном в 2001 году. Если кратко, то звучат они следующим образом:

1. Главное - это люди, а не вещи.
2. Сотрудничайте, а не читайте контракт.
3. Документация не должна мешать работать.
4. Меняйтесь настолько быстро, насколько это возможно.

Может показаться, слишком расплывчато и не точно, но давайте детализируем.

Устройство процессов

Рассматривая, что такое Agile, давайте обратимся к одной из самых популярных методичек, известной как "Скрам" (Scrum). Что же она предлагает? Для начала нужно:

1. Выбрать владельца продукта. На эту роль подходит человек, что видит, к какой цели нужно идти, и что будет в конечном итоге.
2. Определиться с командой. Для этого необходима группа, численностью от трех до десяти человек, что владеют навыками, позволяющими получать результат.
3. Выбрать ответственного специалиста. Это человек, что будет следить за развитием проекта и помогать команде обходить трудности.
4. Разобраться с трудностями. Следует собрать в одном месте все существующие требования к продукту и расставить приоритеты. Владелец продукта должен собрать здесь все свои пожелания. Потом команда их оценивает и разбирается, можно ли это реализовать, и сколько времени для этого нужно.
5. Следует разбить весь объем работ на отрезки времени, длиной в неделю или две, во время которых команда будет выполнять определённые наборы задач.
6. Ежедневно следует проводить встречи, длиной не более пятнадцати минут. На повестке следует обговаривать, что было сделано вчера, какие планы на сегодня, и преграды, мешающие брать высоту.
7. Делать обзоры по итогам недели (двух), во время которых командой рассказывается о том, что было сделано. При этом необходимо демонстрировать работоспособность частей продукта.
8. После каждого временного периода необходимо обсуждать проблемы и искать решения. Причем все наработки необходимо внедрять сразу.

Как опознать Agile?

Методология управления независимо от выбранного направления всегда обладает такими особенностями:

1. Минимизация рисков. Это главная цель, которую преследует любой гибкий подход.
2. Итеративная разработка. В данном случае подразумевается работа в небольших циклах.
3. Самое важное - это люди и коммуникация между ними.

Давайте представим реку. На одном берегу заказчик. На втором - команда. В таком случае гибкая методология разработки имеет преимущества для всех:

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

Социальный фактор

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

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

Небольшой пример

Давайте рассмотрим, как работают эти методологии разработки ПО. Допустим, у нас есть Пётр, владелец продукта. Он не знает технических деталей, зато у него есть видение общей картины. Он знает, зачем нужен продукт, какие проблемы он будет решать, и кого удовлетворит. Также есть заинтересованные лица. Они могут использовать продукт, поддерживать его создание или же как-то ещё быть вовлеченными в его создание. Можно внести ещё и пользовательские истории, в которых выражаются пожелания заинтересованных лиц. Например: система бронирования билетов на рейсовые автобусы Москва-Санкт-Петербург должна иметь поиск по рейсам. Пётр будет помогать заинтересованным лицам. Он возьмёт под контроль реализацию из идей пользовательских историй. Также есть команда разработчиков. Это люди, что будут строить рабочую систему.

Поскольку используется гибкая методология разработки, то пользовательские истории не копятся до большого релиза, а выпускаются сразу после завершения и как можно чаще. Количество обработанных обращений составляет пропускную способность команды на неделю. Чтобы не потерять темп и не увязнуть в ручном тестировании, команда должна работать над автоматизированной интеграцией. В чем она заключается? Для каждого рабочего момента пишется автоматический тест. Если историй слишком много, то может возникнуть спешка, потеря мотивации, снижение производительности и качества. На такие случаи предусмотрен метод «вчерашняя погода». Он заключается в том, что нужно установить жесткие рамки количества работы и тщательно выбирать, что именно будет реализовываться. Упомянутый ранее "Канбан" предлагает устанавливать лимит задач.

А что делать с очередью?

Ладно, вот команда решила, что она может обрабатывать четыре истории на неделю. Но как сориентироваться во всём, что есть? Допустим, пользователи подкидывают по десять историй на неделю. Обрабатывается четыре. Таким образом, очередь будет постоянно расти. На этот случай есть только один эффективный метод - слово "нет". Для владельца продукта это чрезвычайно важно. Сказать «да» не трудно. Значительно сложнее и важнее решить, что не нужно делать. Причем за это необходимо ещё и нести ответственность. Поэтому следует решать, чему уделять внимание сейчас, а что следует отложить. Чтобы правильно нужно чтобы владелец продукта понимал ценность и объем каждой истории.

Принимаем решения

Часть историй чрезвычайно нужна. Другие же просто представляют собой приятный бонус. Одни истории будут разрабатываться несколько часов. На создание других уйдут месяцы. Многие часто проводят соотношение между размером истории и её ценностью. Но это не всегда правильно. Больше - не равнозначно лучше. Петру правильно рассматривать приоритеты помогает сложность и ценность выполняемой задачи. Как определить эти характеристики в количественном значении? Да никак. Это настоящая игра в угадайку. И для большей эффективности в неё необходимо вовлекать достаточно много людей. Это и команда разработчиков, которая проинформирует про объем работ, и заинтересованные лица. Но следует понимать, что все данные, полученные таким способом, представляют собой приблизительные догадки. Здесь не бывает точных цифр. Первоначально будут промахи. Но по мере получения опыта их количество и масштаб будут понижаться.

Возможные риски

Для избегания проблем необходимо дать честные ответы на ряд вопросов. Это:

1. Правильные вещи ли мы делаем? Это бизнес-риск.
2. Можем ли мы реализовать то, что нужно?
3. Будет ли работать проект на данной платформе. Это технический риск.
4. Хватит ли денег, и успеем ли? Это риски сроков реализации и стоимости.

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

Как обучиться?

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

Что ждёт в будущем?

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

В заключение

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

Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться "осязаемый" продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.

Одной из основных идей Agile, является взаимодействие внутри команды и с заказчиком лицом к лицу, что позволяет быстро принимать решения и минимизирует риски разработки программного обеспечения, поэтому команду размещают в одном месте, с географической точки зрения. Причем в команду входит представитель заказчика (англ. product owner - полномочный представитель заказчика или сам заказчик, представляющий требования к продукту; такую роль выполняет менеджер проекта от заказчика или бизнес-аналитик).

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

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

Agile-манифест разработки программного обеспечения:

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.
Это привело к критике этих методов как недисциплинированных.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт - основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота - искусство минимизации лишней работы - крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Критика Agile

Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.

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

Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile - Scrum т.к. в манифести используются термины именно из этого фреймворка):

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

• эпики (epics) - это просто проекты
• пользовательские истории (user stories) - это просто сценарии использования (use case)
• спринты (sprints) - это просто работа
• стенд апы (stand-ups) - это просто совещания
• итерации (iterations) - это просто версии
• бэклоги (backlogs) - это просто список дел
• скорость команды (velocity) - это просто результаты
• и эти задачи (tasks) - это реально, просто задачи

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

Разновидность методологий гибкой разработки

На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки:

• Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
• Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
• Agile Data Method (ADM) - набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
• Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
• Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
• Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
• Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
• Getting Real (GR) - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
• OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
• lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
• Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Аспирант «Нетологии» Максим Пименов рассказывает про Agile — гибкую методологию разработки программного обеспечения.

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

Чтобы процесс создания программы шел правильно, программисты используют методологии. Методология — это набор стратегий и способов создания продукта. Их много и новичок не знает, что выбрать: RUP, XP, Waterfall или другой набор букв.

Возвращаемся к спринту. Во время него команда работает по модели, близкой к каскадной. Каждую новую функцию проектируют и программируют, а затем тестируют и документируют. Когда спринт завершен, команда имеет работоспособную, полезную и более совершенную версию продукта.

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

Пары «план — спринт» идут одна за другой, пока живет проект.

Команда работает как захочет

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

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

В конце каждого спринта команда обсуждает, как работать эффективнее. Это называется ретроспективой. Суть Agile не только в постоянном улучшении продукта, но и в постоянном совершенствовании командной работы.

На самом деле не все любят Agile

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

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

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

Agile подталкивает к мысли: то, что функция работает, намного важнее того, как она реализована. На дистанции такой подход приводит к проблемам. Единственная страховка — сверхдисциплинированная и организованная команда.

Если забыть о философии, ничего не выйдет

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

Помните, в начале статьи я говорил про принципы? Несмотря на их наивность, принципы — самое ценное в Agile. Сначала нужно осознать их и только потом браться за инструменты и практики.

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

Люди бездумно следуют инструкциям, забывая, что Agile — это идеология и философия. А забывать нельзя: если не проникнуться духом методологии, сквозь нее пробьется «водопад» пополам с анархией и бюрократией.

Agile — мировоззрение, а не набор советов. Примите Agile, и только потом беритесь за практику.

Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

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

(Управляющий партнер ScrumTrek Алексей Пименов в на Rusbase)

Слово экспертам

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

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

История Agile

Эволюционное управление проектами и адаптивная разработка программного обеспечения появились в начале 1970-х годов. В 1970 году доктор Уинстон Ройс представил документ под названием «Управление развитием крупных программных систем», в котором критиковалась последовательная разработка. Он утверждал, что программное обеспечение не должно разрабатываться как автомобиль на сборочной линии, в котором каждая деталь добавляется в последовательные фазы. В таких последовательных этапах каждая фаза проекта должна быть завершена до того, как начнется следующий этап. Доктор Ройс рекомендовал использовать фазовый подход, в котором разработчики сначала собирают все требования проекта, а затем завершают всю свою архитектуру и дизайн, затем записывают весь код и т.д.

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы. К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD). Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

В феврале 2001 года семнадцать разработчиков ПО встретились на курорте Snowbird в штате Юта, чтобы обсудить легкие методы разработки. Вместе они опубликовали Манифест о гибкой разработке программного обеспечения Agile.

Манифест Agile

Манифест Agile состоит из 4 основополагающих идеи и 12 принципов. Каждая методология Agile применяет эти идеи по-разному, но все они полагаются на них, чтобы управлять проектами максимально эффективно.

4 идеи Agile

1. Люди и взаимодействие важнее процессов и инструментов.
2. Рабочее программное обеспечение важнее документации.
3. Сотрудничество с клиентами важнее согласования условий контракт.
4. Готовность внести изменения в приоритете, нежели придерживаться первоначального плана.

12 принципов Agile

1. Удовлетворенность клиентов за счет ранней и непрерывной поставки программного обеспечения. Клиенты более счастливы, когда они получают рабочее программное обеспечение через регулярные промежутки времени.
2. Вносить изменения требований к продукту на протяжении всего процесса разработки.
3. Частая поставка рабочего программного обеспечения (каждый месяц, две недели, неделю и т.д.).
4. Сотрудничество между заинтересованными сторонами (заказчиком и разработчиками) на протяжении всего проекта.
5. Поддержка, доверие и мотивация вовлеченных людей. Мотивированные команды с большей вероятностью выполняют свою лучшую работу, чем сотрудники, недовольные условиями труда.
6. Взаимодействие лицом к лицу. Коммуникация более успешна, когда команды разработчиков имеют возможность общаться напрямую.
7. Рабочее программное обеспечение является основной мерой прогресса. Предоставление функционального программного обеспечения клиенту является конечным фактором, который измеряет прогресс.
8. Поддержка постоянного темпа работы. Команды устанавливают повторяемую и поддерживаемую скорость работы, с которой они могут доставлять функционирующее программное обеспечение.
9. Внимание к техническим деталям и дизайну. Правильные навыки и хороший дизайн позволяют команде поддерживать темп, постоянно совершенствовать продукт и работать над изменениями.
10. Простота.
11. Самоорганизующиеся команды поощряют отличную архитектуру, требования и проекты. Квалифицированные и мотивированные члены команды, которые обладают полномочиями принимать решения, регулярно общаются с другими членами команды и обмениваются идеями, которые обеспечат создание качественного продукта.
12. Постоянная адаптация к изменяющимся условиям, что поможет сделать продукт более конкурентоспособным на рынке.

Основа метода Agile

Основой метода гибкого управления проектами является ряд ключевых элементов:

1. Визуальный контроль. Участники проекта в ходе работы над проектом используют карточки различных цветов и видов, которые сигнализируют, какой элемент конечного продукта уже разработан, спланирован, завершен и т.д. Таким образом, команда имеет наглядное представление о существующем положении дел. Визуальный контроль обеспечивает одинаковое видение проекта каждым из участников.
2. Все участники проекта работаю рядом, включая клиента. Такой подход не только ускоряет многие процессы, связанные с информированием участников рабочей группы, но и создает благоприятную атмосферу для сотрудничества и эффективной работы.
3. Адаптируемое управление. Руководитель проекта – не человек, который раздает указания, а лидер, определяющий основные правила работы и сотрудничества.
4. Совместная работа. Команда, руководитель проекта и клиент работают сообща, что исключает возможность потери информации и непонимания целей. Также прозрачность всех процессов позволяет моментально исключать появившиеся проблемы и находить удачные решения и улучшения.
5. Работа, основанная на разделении общего объема проекта на составные части. Такая система работы значительно снижает сложность проекта и позволяет командам сфокусироваться на каждой части в отдельности.
6. Работа над ошибками. В ходе работы одного цикла команда осваивает новые навыки и анализирует произошедшие ошибки, что исключает их появление в следующем цикле.
7. Спринты и ежедневные встречи. Спринты – отрезки времени, за которые команды выполняет ряд задач, — позволяют четко видеть результаты работы. Разделив время работы над проектом на спринты, получаем, например, 10 спринтов, каждый по две недели. А ежедневные встречи не более чем на 15 минут помогут каждому члену команды ответить для себя на три вопроса: что я делал вчера, что я буду делать сегодня, что мне мешает выполнять работу?

Таким образом, внедрение гибкого метода Agile возможно при следующих условиях:

• значение проекта четко обозначено,
• клиент активно участвует на протяжении всего проекта,
• возможно пошаговое выполнение общего объема проекта,
• результат работы важнее, чем документация,
• рабочая группа составляет не более 7-9 человек.

На данный момент методология Agile широко распространена в IT-сфере и начинает осваивать деловую сферу, в частности маркетинг, менеджмент, обучение и т.д.. Метод гибкого управления проектами используется многими компаниями и госструктурами, например, правительства Норвегии и Новой Зеландии применяют Agile. В России «Сбербанк» осваивает Agile для коммерческой сферы.

Системы управления проектами, основанные на Agile

Существует множество методов, основанных на идеи Agile, самые популярные из них — Scrum и Kanban.

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы. Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч. Сам метод представляет собой процесс разработки, разделенный на небольшие итерации — спринты, по завершении которых пользователи получают улучшенный вариант ПО. Спринт жестко фиксирован по времени, а его длительность составляет от 2 до 4 недель. Работа в рамках одного спринта состоит из нескольких этапов:

1. Планирование объемов работы для одного спринта.
2. Ежедневные совещания на 15 минут для коррекции работы команды и подведения промежуточных итогов.
3. Демонстрация результатов работы.
4. Ретроспектива спринта, в которой рассмотрены удачные и неудачные события в рамках прошедшего спринта.

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

Scrum значительно увеличивает производительность и сокращает время до преимуществ по сравнению с классическими процессами «waterfall». Процессы Scrum позволяют организациям плавно адаптироваться к быстро меняющимся требованиям и создавать продукт, отвечающий изменяющимся бизнес-целям. Scrum позволяет:

• Повысить качество результатов;
• Лучше справиться с изменениями;
• Обеспечить более точные оценки, тратя меньше времени на их создание;
• Лучше контролировать сценарий проекта и этапы работы.

Kanban

Kanban — это процесс, призванный помочь командам работать вместе более эффективно. В переводе с японского kanban обозначает “рекламный щит, вывеска”, а сам метод взят и адаптирован с производственной системы Toyota. Суть Канбан заключается в том, чтобы сделать процесс разработки максимально прозрачным и распределять нагрузку равномерно между членами команды. Канбан способствует непрерывному сотрудничеству и поощряет активное, постоянное обучение и совершенствование.

Kanban основан на трех принципах:

1. Визуализация задач: видимость всей информации о проекте поможет увидеть недочеты, ошибки и накладки.
2. Контроль и ограничение WIP (work in progress — работа, выполняемая одновременно): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не совершали слишком много работы сразу.
3. Контроль времени на выполнение задачи и оптимизация работы для экономии времени.

Достоинства и недостатки Agile

Любая методология имеет преимущества и недостатки. Рассмотрим плюсы и минусы Agile.

Преимущества

1. Больше гибкости по сравнению с методологией Waterfall.

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

2. Меньше дефектов в конечном продукте.

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

Недостатки

1. Постоянное получение обратной связи приводит к постоянному переносу даты завершения проекта.

Благодаря мгновенной обратной связи, которую предоставляет Agile, возникает опасность долгой работы. Конечные пользователи, которые видят, что эти требования могут быть выполнены «легко» (они видят только результат, а не усилия), будут запрашивать дополнительные функции. Если менеджер проекта и разработчики не могут управлять ожиданиями, конечные пользователи будут продолжать запрашивать больше, пока вся команда не будет загружена дополнительной работой.

2. Документация

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

3. Частые встречи

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

Внедрение Agile

1. Выбор методики. Существуют различные гибкие методологии, которые разработаны под определенные условия. Первым этапом работы с Agile необходимо определить цели задачи работы, сроки, количество сотрудников и многое другое и подобрать такую гибкую методику управления проектом, которая будет отвечать всем требованиям.
2. Обучение персонала. Обучение необходимо для того, чтобы сотрудники понимали базовые принципы Agile и знали как с ними работать. Именно на этом этапе определяются подводные камни, которые могут снизить эффективность Agile. Готов ли коллектив к изменениям? Подходят ли проекты компании для гибких методик? На эти и многие другие вопросы обычно помогают ответить бизнес-тренеры, специализирующиеся на Agile. Помимо прочего будет также составлен список тренингов и план, по которому будет вестись внедрение Agile в компании.
3. Демонстрация Agile. Своеобразный тест-драйв Agile, которые проводится под контролем специалиста и показывает все этапы работы, объясняет функции ролей, взаимодействие внутри команды и между командами и т.д.
4. Создание команды. В создание команды помимо подбора сотрудников также входит определение обязанностей, распределение задач, создание графика встреч и т.д. Каждая из методик рассчитана на определенное количество человек в команде.
5. Выбор инструментов , необходимых для распределения задач, ведения отчетности, аналитики и прочее.
6. Первый проект с Agile. В первом проекте будут ошибки, несостыковки, отказ от одних инструментов и выбор других. Любая методика требует своеобразной адаптации под особенности компании, в которую она внедряется.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .