Agile - как это

Источник: http://www.voznjak.com/content/agile-kak-eto

Слово Agile последних 7-8 лет очень на слуху и весьма популярно. В наши дни вряд ли
найдется кто-то из IT-отрасли, кто не слышал бы слово Agile или Scrum или
словосочетания с ними. В этой статье будем разобраться с понятием Agile и тем, что
стоит за этим словом.

С чего ж все началось?

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

Появилась
эта модель в 1956 году и была она представлена Хербертом Беннингтоном –
человеком, который участвовал в разработке большой системы американской военной
промышленности в 50-е годы в период холодной войны. Поэтому все, что так или
иначе связанно с IT, напрямую привязано к военным оборонительным проектам. В
1956 году на симпозиуме Беннингтон представил методы управления проектами и
разработкой в общем. Тогда же он озвучил некие стадии проекта, которые своими
корнями уходят еще в конвейерное производство.
Первые упоминания о waterfall
В 1970 году Уинстон Ройс опубликовал статью, в которой впервые ввел термин
waterfall. Ошибочно считать, что он является автором или адептом каскадной модели.
Ведь он в своей статье критиковал данную модель и говорил о том, что в жизни такого
прямого процесса не бывает, так или иначе он зацикливается.
В 1983 году Херберт Беннингтон написал, что действительно в жизни все работает не
совсем по процессу, который он ранее описал, и этот процесс все же зацикливается.
Важно понимать, что в те годы проекты были связаны в основном с оборонительными
военными разработками, а это были достаточно большие проекты, максимально
формализованы и связаны с большой степенью риска.
В 1970-80 годы начали говорить о том, что waterfall итерационный и именно в этот
период появилось огромное количество различных модификаций каскадных моделей,
например, RUP (Rational Unified Process).

Что в RUP было нового по сравнению с каскадной

моделью?
В первую очередь, это итерации.

Кроме того, этот процесс был инкрементальный. То есть в конце каждой итерации
надо было получить существенный прирост к продукту - инкремент. Как результат,
каждая итерация выдавала какой-то существенный результат (в каскадной модели
результат получали только в конце). Именно в RUP были сформулированы так
называемые пользовательские сценарии и вовсю пропагандировалось описание
требований в виде этих сценариев. Это позволяло разработчикам смотреть на
систему со стороны пользователей. Главные люди этого процесса были архитекторы,
так как все требования и построение системы развивались вокруг архитектуры.
Также в RUP была разработана полноценная система работы с рисками.
RUP появился и был сформулирован в 1999 году, такими людьми как: Ивар Якобсон,
Гради Буч, Джеймс Румбах.
Кратко о RUP
● Итеративный и инкрементальный.
● Основан на пользовательских сценариях.
● Архитектура является образующей.
● Акцентирован на риски.

Agile - начало
В конце 90х годов возникло некое недовольство в IT сообществе существующими
процессами.

Не смотря на то, что фокус уже сменялся к итеративной разработке, к взгляду на

систему со стороны пользователей, все же степень формализма и работы с
множеством документации была очень велика. Это привело к тому, что в IT
сообществе все больше и чаще были слышны мнения по поводу того, что это
избыточно, что это не работает в сфере IT и современных систем, что чем дальше,
тем системы становятся более мобильными, тем чаще меняются требования и тем
важнее становится адаптация к меняющимся требованиям. То есть стали появляться
обычные заказные системы, в которых требования менялись часто, так как заказчик на
самом раннем этапе разработки часто не знал, что точно он хочет получить в конце
проекта.
Все это произвело к тому, что в 2001 году 17 ведущих специалистов IT отрасли
собрались вместе и сформулировали так называемый Agile Manifestо. Это были
ключевые принципы, на которые они опираются в своей работе.

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

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

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

2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что
слева.
Важно понимать, что мы не отрицаем то, что написано в правой части манифеста. Мы
только говорим о том, что мы больше ценим написанное в левой части чем то, что
написано в правой части.

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

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

В каких проектах Agile не работает?

Ответ можно понять из принципов, которые перечислены выше.
Agile плохо работает там, где нет взаимоуважение, где заказчик не готов учувствовать
и сотрудничать в разработке продукта, например, большие государственные
структуры.
Важно заметить, что Agile хорошо работает в условиях динамично изменяющихся
требований. При этом не все проекты живут по таким правилам. Большинство да, но
все равно остаются те же банковские системы, медицинские системы, у которых нет
потребности в изменении требований, но есть потребность в высоком уровне
надежности. То есть остаются отрасли, в которых процесс изменения требований не
так уж и нужен, важно вначале детально описать требования и потом их просто
реализовывать. В таких случаях уже на старте проекта понятно, что должны получить
в конце. Здесь очень высока цена ошибки. Если в какой-то области цена ошибок очень
велика и требования достаточно сильно детерминированы на самом старте, то Agile
здесь не нужен.
Очевидно также, что Agile также не будет работать в тех командах, которые не хотят
учиться, совершенствоваться.
В чем же разница между waterfall и Agile?

В классических каскадных моделях вначале проекта фиксируются требования и затем

в случае изменений внешних обстоятельств, сработавших рисков и прочего, начинает
корректировать время и бюджет.
Agile же говорит о том, что мы должны скорее спланировать наши ресурсы и время, но
можем корректировать содержание.
Какие же существуют Agile методологии?
Существует много различных Agile методологий, некоторые из низ изображены на рис.
2. Это некий свод методологий - определённых правил работы, которые позволяют

достигать принципов Agile.

Немного о некоторых из методологий Agile.

Feature Driven Development (FDD), 1997 г.

Методология Feature Driven Development (FDD) изначально была разработана Jeff De
Luca. Основные практики, описанные в FDD, следующие:
● Моделирование объектной модели домена.
● Разработка на основе фич.
● Индивидуальное владение кодом.
● Команды, организованные по фичам.
● Инспекции.
● Управление конфигурацией.
● Регулярные сборки продукта.
● Видимость прогресса и результатов.
Интересно то, что практика индивидуального владения кодом вступает в противоречие
с концепцией коллективного владения кодом, что сегодня является ключевой
практикой.

Dynamic Systems Development Method (DSDM), 1994 г.

В отличие от остальных практик и методологий, DSDM был разработан консорциумом,
являющимся объединением поставщиков и производителей программного
обеспечения. Целью их работы было - совместными усилиями разработать и
распространить независимый фреймворк для быстрой разработки приложений, с
использованием накопленного опыта. Нет одного лишь человека, которого можно
считать создателем этого метода, однако, Jennifer Stapleton являясь одним из
основателей и членом DSDM, внесла существенный вклад в компиляцию исходных
идей и мыслей.
Arie van Bennekum является одним из автором Agile-манифеста и принимал активное
участие в работе консорциума DSDM начиная с 1997 года. DSDM фокусируется на
восьми основных принципах:
● Фокус на потребностях бизнеса.
● Поставлять во время.
● Взаимодействовать.
● Никогда не снижать качество.
● Создавать постепенно с самых основ.
● Разрабатывать итерационно.
● Непрерывно и ясно общаться.
● Демонстрировать управляемость.
И вновь вы можете видеть основы Agile-манифеста.

Crystal Methods, 1992 г.

Семейство методологий Crystal послужила отправной точкой в развитии методологий
разработки программного обеспечения, что в итоге привело к тому, что мы сейчас
называем Agile-движением. Честь создания Crystal принадлежит Алистеру Коберну
(Alistair Cockburn). Методология была названа Crystal в 1997 году. Методология может
быть применима к командам, состоящим из 6 - 8 участников, расположенных в одном
месте, работающих над созданием программных систем, не являющихся критичными
для жизни пользователей. Вы можете обнаружить зачатки Agile-манифеста в
методологии Crystal, поскольку она фокусируется на:
● Частой поставки работающего кода конечным пользователям.
● Разумных улучшениях.
● Всепроникающей коммуникации (osmotic communication) между членами
команды, расположенными в одном месте. Под всепроникающей
коммуникацией подразумевается непосредственная передача информации, в
том числе путем подслушивания или наблюдения за вещами, происходящими
вокруг.

XP (Extreme programming), 1995 г.

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких
методологий разработки программного обеспечения. Авторы методологии — Кент Бек,
Уорд Каннингем, Мартин Фаулер и другие. Эта методология сфокусирована на
разработке качественного продукта. В ней много разработчиских практик, например:
● Парное программирование. Техника программирования, при которой исходный
код создаётся парами людей, программирующих одну задачу, сидя за одним
рабочим местом. Один программист («ведущий») управляет компьютером и, в
основном, думает над кодированием в деталях. Другой программист
(«штурман») сосредоточен на картине в целом и непрерывно просматривает
код, производимый первым программистом. Время от времени они меняются
ролями, обычно, каждые полчаса.
 ● Test-driven development (TDD). Разработка через тестирование — техника
разработки программного обеспечения, которая основывается на повторении
очень коротких циклов разработки: сначала пишется тест, покрывающий
желаемое изменение, затем пишется код, который позволит пройти тест, и под
конец проводится рефакторинг нового кода к соответствующим стандартам.
● Непрерывная интеграция (CI, англ. Continuous Integration). Это практика
разработки программного обеспечения, которая заключается в выполнении
частых автоматизированных сборок проекта для скорейшего выявления и
решения интеграционных проблем. В обычном проекте, где над разными
частями системы разработчики трудятся независимо, стадия интеграции
является заключительной. Она может непредсказуемо задержать окончание
работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость
интеграции и сделать её более предсказуемой за счет наиболее раннего
обнаружения и устранения ошибок и противоречий. Он нацелен на то, чтобы
команда отвечала за качество продукта и дает им для этого соответствующие
инструменты.

Scrum, 1995 г.

SCRUM был разработан совместно Джефом Сазерлендом (Jeff Sutherland) и Кеном

Швабером (Ken Schwaber), которые представили доклад на конференции OOPSLA ’95
в Остине штат Техас. Джеф Сазерленд занимает пост CEO в компании Scrum, Inc. Кен
Швабер является основателем Scrum.org.
Mike Beedle был одним из первых евангелистов Scrum и внедрил эту методологию во
много организаций, начиная с середины 90-х. Scrum является фактически стандартом
де-факто для гибкой разработки.
Scrum методология делает основной акцент на общении с заказчиком, на общении
внутри команды, достижении самоорганизации, достижении высокого уровня
самосовершенствования.
Три основных момента в Scrum:
1. Временные рамки.
2. Роли.
3. Практики.
Роли
Scrum вводит свои роли для всех людей работающих над проектом:
● Команда. Это команда разработчиков - основная движущая сила. Она состоит
из профессионалов, которые работают над созданием инкремента продукта.
Scrum требует, чтобы команда разработки была кроссфункциональна, то есть
содержала людей со всеми необходимыми знаниями у умениями для того,
чтобы создать каждый инкремент продукта.
● Product Owner. Человек, который владеет видением продукта, отвечает за то,
что продукт движется в нужном направлении. Он ответственный за
определение того, что же будет являться наиболее ценным и возможным
продуктом к желаемой дате. Это делается посредством управления работой,
которая поступает команде, выбором и уточнением элементов Бэклога
Продукта. Product Owner поддерживает Бэклог Продукта и заботиться о том,
чтобы все знали, что в нем находится и какие приоритеты расставлены. Также
стоит заметить, что Product Owner типично является человеком, наиболее
приближенным к «бизнес стороне» проекта. Обычно он наделен полномочиями
в организации, чтобы «вытолкнуть этот продукт» и чаще всего
подразумевается, что этот тот человек, который сможет лучше других
удовлетворить пожелания всех заинтересованных сторон.
● Scrum Master. Человек, который отвечает за то, что команда разрабатывает
продукт эффективно. Он должен иметь хорошее понимание фреймворка
Скрама и способен учить других тонкостям этого процесса. Скрам Мастер
работает вместе с Product Owner-ом, помогает ему понимать, создавать и
поддерживать Бэклог Продукта. Он работает с командой разработки, пытается
найти и внедрить технические практики, которые позволят команде достичь
нужного состояния готовности продукта по окончанию Спринта. Скрам Мастер
помогает всем улучшаться, чтобы Scrum Команда стала более эффективной и
ценной.

Временные рамки
Scrum достаточно жестко фиксирует временные рамки на свои практики. Scrum чётко
фиксирует длину итерации (от 1 до 4х недель).

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

Существует так называемый Product Backlog – список идей, требований, хотелок,

пожеланий, фич и т.д. Главный человек, который за ним следит – Product Owner. Это
его инструмент. Product Backlog всегда приоритизирован и чем выше приоритет, тем
более важно требование для конечного результата. Каждый раз в начале нового
спринта команда из Product Backlog забирает верхушку, так называемый Sprint
Backlog. Это также список задач, но уже более конкретных задач на спринт. Смысл в
том, чтобы Product Owner постоянно следил, что на верхушке Product Backlog
находились самые приоритетные требования, которые в первую очередь нужны с
точки зрения бизнеса. Затем команда оценивает трудоемкость с помощью разных
инструментов и берет из них тот кусок, который она сама чествует и верит, что успеет
сделать в течение итерации. Здесь важно понимать, что когда команда сама берет
желаемый объем задач, то тогда она и более ответственно относиться к их
выполнению. Внутри спринта есть также ежедневные итерации, которые
поддерживаются таким инструментом как stand-up митинги. Эти митинги проводятся
каждый день в одно и то же время и на них обсуждается ситуация по задачам. Обычно
на stand-up митинге обсуждается три основных вопроса: что сделано? что планируем
делать? есть ли какие-то проблемы? За все что происходит внутри Спринта (stand-up
митинги, следования), контроль того, что разработка движется с нужной скоростью и
т.п. отвечает Scrum Master. В конце спринта проводится демо и ревью спринта.
Команда демонстрирует инкремент продукта, созданный за последний Спринт. Product
Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают.
Команда рассказывает о поставленных задачах, о том как они были решены, какие
препятствия были у них на пути, какие были приняты решения, какие проблемы
остались нерешенными. На основании ревью принимающая сторона может сделать
выводы о том, как должна дальше развиваться система. Участники миитинга делают
выводы о том, как шел процесс в команде и предлагает решения по его улучшению.
Скрам Мастер отвечает за организацию и проведение этого митинга. Команда
помогает ему составить адженду и распланировать кто и в какой последовательности
что представляет.
Дальше все по новой.