Методы agile

9.1 Методы и методология

Начнем с объяснения смысла понятий, вынесенных в заголовок.

9.1.1 Терминология

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

9.1.2 Лиса и еж

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

9.2 Lean Software и Kanban

Вдохновленные успехом японских автомобилестроителей, особенно процессом производства "Тойоты", на методы "экономного производства" обратили внимание многие отрасли индустрии. Они стремились сделать индустриальное производство более эффективным, не строя никакой части продукта, если в ней не было явной необходимости, задерживая производство необходимых элементов до тех пор, пока потребители или производственная необходимость явно не потребует эти элементы (производство "на лету" М just-in-time). Все коммуникации без явной необходимости минимизировались, на каждом шаге минимизировались затраты.

Мэри и Том Поппендик перенесли эти идеи на производство программных продуктов, назвав метод "экономное программирование" (Lean Sowtware Devolpement).

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

9.2.1 Большая идея экономного программирования (Lean)

Lean одержим идеей:

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

9.2.2 Принципы Lean

Метод Lean предлагает семь принципов:

Принцип 1 (исключение затрат) наиболее важен. Он включает в "затраты" многие традиционные продукты и виды деятельности. Затратными продуктами являются:

Затратными процессами являются:

Принцип 2 (улучшение обучения) направлен на улучшение качества проекта, поиска лучших решений, обучение программистов на собственном опыте. Он отрицает подход "делай все правильно с самого начала", предлагая другой подход – "попробуй – протестируй – попытайся улучшить".

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

Принцип 4 (поставлять как можно раньше) является общим для всех agile подходов. Производить работающую систему на каждой итерации; давать возможность потребителям тестировать ее; получать преимущества от обратной связи.

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

Принцип 6 построения целостной системы исходит из необходимости построения согласованного решения. Он близко связан с понятием простоты решения в XP.

Принцип 7 (видение целого) заставляет концентрироваться на том, что действительно важно, на всей картине, не сосредоточиваясь на малых ценностях. К последним относятся:

9.2.3 Экономное программирование. Оценка Lean

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

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

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

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

9.2.4 Канбан

Хотя метод Kanban отличается от метода Lean, он вырос из того же источника – процесса производства продукции в фирме "Тойота". Этот метод завоевал некоторую популярность в программистских кругах как дополнение Lean или Scrum.

Большая идея Канбан – минимизация незавершенного производства, что обеспечивается поставкой продукции "по требованию". "Карты Канбан" служат для отслеживания необходимых материалов и сигнализируют в случае отсутствия нужных деталей. Панель Канбан подобно панели Scrum визуализирует прогресс частей и продуктов в процессе производства, отмечая переходы между состояниями "необходимо выполнить", "в процессе выполнения", "сделано".

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

9.3 Экстремальное программирование – XP

Экстремальное программирование является оригинальным agile методом в том смысле, что его появление в конце девяностых годов стало событием, приведшим agile идеи на передний край программной инженерии.

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

9.3.1 Большая идея XP

Большая идея XP может быть сформулирована следующим образом:

Это основной цикл, повторяемый, пока разработчики не сделают потребителей счастливыми. Добавляется функциональность, индуцированная TDD (Test Driven Development) с новым тестом, падающим на системе без добавленного кода. Когда все начинает работать, ищутся те повреждения, которые новый код мог нанести простоте системы. Применяется рефакторинг, восстанавливающий простоту.

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

9.3.2 XP: источник

Замечания по поводу описания экстремального программирования помогут тем читателям, которые захотят глубоко изучить XP, помимо того представления, которое дается в этой книге. Хотя различные авторы, в частности Джеффри и Каннингэм, написали хорошие статьи и книги по XP, настоящим источником является книга Бека "Extreme Programming Explained". Книга выдержала два издания, в 2000 и 2005 годах, и вопреки ожиданиям я нахожу первое издание лучшим источникомИмеется русский перевод первого издания: Кент Бек "Экстремальное программирование", Питер, 2002 г.. Во втором издании чувствуется обида автора на некоторые комментарии к первому изданию. Вот небольшая выдержка из второго издания:

(Странно: как кто-то купивший книгу по методологии программирования, может жаловаться на то, что ему говорят "программируйте определенным способом".) В результате он смягчил тональность сообщений, уйдя от конкретных, а следовательно, критикуемых утверждений к более нейтральным, но менее интересным обобщениям. Показательным примером является выдержка из первого издания:

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

Конечно, такие вежливые банальности никого не обидят. Но в них нет ничего экстремального. И чему они учат? Я отдаю преимущество откровенной простоте первого издания. Это замечание касается сущности, а не стиля. Хотя во втором издании приводятся agile практики, зачастую это делается настолько абстрактно, что необходимо обратиться к оригинальной книге для получения точного описания.

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

9.3.3 Ключевые техники XP

Многие из принципов и практик, обсуждаемых в предыдущих главах, впервые представлены в XP. Книги по XP включают длинные списки практик, но основные приемы (в соответствии с терминологией этой книги не только практики, но принципы и артефакты) включают:

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

9.3.4 Экстремальное программирование: оценка

Экстремальное программирование обеспечило начальный толчок, благодаря которому на agile методы обратили внимание в программистском мире. Слово "экстремальное" использовалось намеренно, подчеркивая, что лучшие практики расширяются экстремальным способом. Как объяснялось в вышеприведенном отрывке из первого издания книги Кента Бека (если X хорош, то будем применять его непрерывно во всем диапазоне практики X), экстремальность связана и с общими утверждениями метода, в которых настаивается, что предлагаемые техники не только возможны, но и обязательны, например, программировать нужно парами.

Можно характеризовать эти утверждения как догматизм, но в этом одна из сильных сторон метода – его согласованность. XP настаивает на том, как следует программировать, оставляя мало пространства для компромиссов. Эта позиция препятствовала принятию XP сообществом. Но многие индивидуальные приемы XP получили признание в индустрии, и не только командами, которые явно следовали agile процессу. Экстремальное программирование предложило миру упомянутые выше практики:

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

9.4 Scrum

Scrum пришел, чтобы доминировать на agile сцене. Численные результаты различных исследований отличаются, но общий тренд неоспорим: Scrum превосходит XP при выборе agile метода. Для полноты картины стоит отметить, что Scrum в большей степени является организационной техникой, и многие команды, принимающие его, добавляют программно специфические концепции XP.

По Scrum имеется многочисленная литература, включающая несколько книг от его создателей – Швабера и Сазерленда. Авторы и Scrum альянс подготовили много доступных документов, учебные пособия, записи лекций, содержащие конкретные детали. Кон и Ларман являются авторами полезных книг по ScrumФирма Microsoft, проявляя интерес к agile, включила возможность разработки проектов по методу Scrum, начиная от планирования спринтов и кончая отслеживанием прогресса, в студию разработки Visual Studio Team Foundation Server – TFS. Полезная книга, где описан этот подход: Стив Резник, Аарон Бьйорк, Майкл де ла Маза "Scrum с Team Foundation Server 2010. Профессиональный подход", 2012..

9.4.1 Большая идея Scrum

Наиболее отличительная черта Scrum – это правило "закрытого окна", рассмотренное в предыдущих главах:

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

Манифест agile наивно декларирует, что аджилисты "приветствуют изменения", но никакая серьезная разработка не может допустить принятие любых изменений в любое время. Ответ Scrum понятен: никакие изменения не допускаются в течение текущей итерации (спринта). Это правило распространяется на всех независимо от роли и ранга. Оно приемлемо, поскольку итерации короткие, так что запрет носит временный характер. Кроме того, это дает возможность "остыть", и к концу итерации решение о добавлении новой функциональности, возможно, не будет казаться столь привлекательным.

Если бы при подготовке этой книги после долгого погружения в проблематику agile методов мне нужно было бы выбрать только одну главную идею, то я остановился бы на этой большой идее Scrum. Принцип инновационный, применимый, эффективный.

9.4.2 Ключевые практики Scrum

Итерации Scrum следуют практикам, рассмотренным в предыдущих главах:

Это только некоторые из наиболее важных элементов. Многие другие приемы Scrum рассматривались в предыдущих обсуждениях.

9.4.3 Scrum: оценка

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

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

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

9.5 Crystal

Имя Crystal обозначает массив методов, разработанных Алистером Кокбурном. Слово "массив" можно понимать буквально. Каждый метод массива характеризует разработку проектов в зависимости от двух критериев – критичности проекта и его размера. Каждый критерий имеет четыре уровня, что в совокупности дает матрицу из 16 окрашенных элементов. Понятно, что только немногие из этих слотов заполнены детальными описаниями методов. Метод Crystal Clear предназначен для работы с небольшими проектами, Crystal Orange был первым разработанным методом и ориентирован на большие проекты.

9.5.1 Большая идея Crystal

Crystal особое внимание уделяет взаимодействию в команде благодаря принципу, который превращает желеобразную группу в единое целое:

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

Так определяется осмотическая коммуникация в версии Crystal Clear. Для больших групп или групп, разделенных пространственно, концепция обобщается на "ядерную коммуникацию".

9.5.2 Принципы Crystal

Crystal определяет семь принципов, представляющих некоторую смесь различных подходов.

9.5.3 Crystal: оценка

Как и Lean, Crystal не является методом, шаг за шагом рассказывающим подробности организации проекта, как это делает Scrum, не предлагает технологические детали, как это делает XP. Crystal – это скорее концентрация программистской мудрости.

Что в наибольшей степени отличает Crystal от других agile подходов, так это отказ от догматизма и принятие некоторых классических принципов программной инженерии. Предложение вариантов метода, адаптируемых к различным видам проектов – критичным или не очень, большим, малым и средним – это тоже свежая инициатива.

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

С позиций истории Crystal можно рассматривать как некий эпизод. Но если подходить с другой меркой, не с точки зрения момента создания, а с учетом развития идей, то XP можно отнести к первому поколению, а Scrum – ко второму. Crystal с его попыткой интегрировать лучшие идеи независимо от их источника, обеспечения реалистичного каркаса для проектов – больших и малых, мог бы вырасти в реальный метод при условии определения точных приемов управления и разработки проектов. В такой ситуации Crystal можно рассматривать как первый шаг на пути создания agile методов третьего поколения.