Аджайл

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

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

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

  Кент Бек, Джеймс Греннинг, Роберт Мартин, Майк Бидл, Джим Хайсмит, Стив Меллор, Ари ван Беннеком, Эндрю Хант, Кен Швабер, Алистер Кокберн, Рон Джеффрис, Джефф Сазерленд, Уорд Каннингем, Джон Керн, Дейв Томас, Мартин Фаулер, Брайан Марик.

  © 2001, вышеперечисленные авторы. Текст манифеста может свободно копироваться в любой форме, но только полностью, включая это уведомление.

Так гласит Манифест аджайл — плод эпохальной встречи программистов, которая состоялась в феврале 2001 г. на лыжном курорте Сноуберд в штате Юта. Движение родилось.

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

Указания на эти и другие ценности «Двенадцать принципов аджайла» можно найти в соответствующем приложении к Манифесту.

Манифест аджайл опирается на 12 принципов:

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

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

Три метода аджайла

Функционально-ориентированная разработка

Джефф Делюка создал методологию функционально-ориентированной разработки (feature-driven development — FDD) в 1997 г. при выполнении проекта для одного сингапурского банка. Как говорится в «синей книге», она вошла в историю канбана в 2004 г., когда Дэвид Андерсон представил ее в компании Motorola. В общем виде процесс FDD изображен на рис. 13.1.

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

Одна из наиболее примечательных особенностей FDD — ее первый этап, разработка общей модели, которая включает в себя подготовку технической модели (модели объекта, возможно, представленную в графическом обозначении на языке Unified Modeling Language) и сопроводительной записки. Изначально это модель очень высокого уровня; она постепенно развивается и дорабатывается по принципу «на данный момент достаточно» в соответствии с обратной связью, поступающей от других четырех этапов, в особенности от этапа проектирования функции.

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

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

В конце 1999 — начале 2000 г. благодаря Томасу (Томми) Зюссли, под руководством которого я тогда работал, у меня на столе неожиданно оказалась только что вышедшая книга. Это была работа Кента Бека «Экстремальное программирование». Должен признать, что поначалу она немного озадачила меня, но потом я увлекся и позднее вложил средства в издание других книг этой серии.

Подобно FDD, экстремальное программирование (extreme programming — XP) предвосхищает появление Манифеста аджайл. Оно признает пять ценностей: коммуникацию, простоту, обратную связь, храбрость и уважение (последнее было добавлено позже). Среди девяти ценностей канбана я не нахожу прямых аналогий простоте (не подумайте, что тут есть какой-то конфликт). При этом коммуникация и обратная связь соответствуют сотрудничеству и прозрачности. Конечно, есть связь между храбростью и лидерством. Уважение в XP прямо соответствует уважению в канбане.

Различия между ХР и FDD бросаются в глаза. Сравните диаграммы FDD на рис. 13.1 и ХР на рис. 13.2, которые делают различия более очевидными.

Я вижу несколько различий:

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

Разгадка скрыта в названии метода: суть ХР — это именно программирование. Зачем начинать процесс с создания модели, когда код сам по себе может быть моделью? Программирование оказывается «экстремальным» благодаря устранению лишних этапов, интенсивной работе в парах и использованию напряженных циклов обратной связи.

Моя любимая связанная с ХР цитата звучит так:

Если это причиняет боль, то делай это чаще и пусть она придет раньше.

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

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

Еще до разработки методологии экстремального программирования Кент Бек был пионером юнит-тестирования. Он создал основанное на открытом исходном коде семейство фреймворков автоматизированного модульного тестирования xUnit с модулем SUnit, реализованным для использования языка программирования Smalltalk. С тех пор были разработаны фреймворки xUnit для других языков, например jUnit для языка Java и Test:: Unit для Ruby. Юнит-тестирование сейчас представляет собой не просто решенную проблему, это мейнстрим. Отметим, что методология разработки через тестирование (test-driven development — TDD) движется в том же направлении.

Автоматизированное приемочное тестирование включает в себя следующее:

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

В этой области также много инноваций. Появились целые сообщества, которые формировались вокруг различных фреймворков и методов спецификации. Некоторые из них, в частности разработка через реализацию поведения (behavior-driven development — BDD), развились настолько, что сами превратились в методологии.

Основанные на использовании открытого исходного кода распределенные системы управления версиями (distributed version control systems — DVCS), например git, позволяют сотням (если не тысячам) программистов участвовать в таких колоссальных проектах, как Linux, которая действительно является результатом совместной работы. Помимо прочего, эти инструменты продолжают формировать основу нескольких решений проблемы внедрения. Все чаще — и это просто превосходно для программистов вроде меня, занятых неполный рабочий день — их встраивают в хостинг-платформы. Теперь добраться до моего последнего творения в интернете можно также просто, как набрать команду git push в командной строке. Непрерывная поставка выжала из автоматизации управления кодами, тестирования и внедрения все возможное. Компании вроде Amazon сегодня выпускают релизы так часто, что средняя продолжительность интервала между ними измеряется секундами!

С учетом того, что весь рабочий поток занимает всего лишь часы или дни, рабочие задачи в ХР должны быть небольшими и пригодными к тестированию. Считая функциональные требования, сценарии использования и наборы функций слишком громоздкими, экстремальное программирование популяризировало так называемые пользовательские истории — записанные на карточках требования к разрабатываемой системе, выраженные одним предложением, часто стереотипно («Как <пользователю> мне нужно <то-то и то-то>, чтобы получить <то-то и то-то>»). Все это также является предметом подробного исследования — на эту тему написаны целые книги.

Методология скрама

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

Скрам представляет собой итерационный и поэтапный фреймворк для разработки программного обеспечения. Он появился в середине 1990-х гг. (подобно ХР, скрам предвосхитил появление Манифеста аджайл). Диаграмма процесса скрам представлена на рис. 13.3.

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

1. Три роли: владелец продукта, скрам-мастер и команда разработчиков.
2. Три мероприятия: совещание по планированию спринта до его выполнения, ежедневное скрам-совещание в течение выполнения спринта и два совещания при закрытии спринта — обзор спринта и ретроспектива спринта.
3. Три основных артефакта: бэклог продукта, бэклог спринта и диаграмма сгорания задач.

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

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

Ритм в скраме является его основным преимуществом и (вполне намеренно) самым большим источником проблем. Достаточно трудно подобрать и затем выполнить нужный объем работы таким образом, чтобы он точно соответствовал отведенному на спринт времени. Если объем работы окажется слишком большим или слишком маленьким, результат будет одинаковым: бесполезная трата времени в команде разработчиков и за ее пределами.

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

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

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

Канбан и аджайл

Совместимость

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

Когда задают подобный вопрос, стоит покопаться немного и выяснить, что именно имеется в виду:

• Совместимы ли ценности канбана и аджайла? Да, абсолютно! Мы видим здесь основания не для сравнения, а для интеграции.
• Может ли канбан «улучшить гибкость», совершенствуя существующий процесс разработки программного обеспечения — построенный на основе аджайла или другого метода — в направлении, полностью согласующимся с ценностями и принципами аджайла? Ответ на этот вопрос — не просто однозначное «да»; метод был разработан именно для этого.
• Является ли канбан, говоря словами манифеста, методом разработки программного обеспечения? Нет. Возможно, мы цепляемся к мелочам, но в этом смысле характеризовать канбан как один из методов аджайла — значит вводить в заблуждение. Канбан никоим образом не является процессом разработки (или какой-либо другой частью процесса, имеющим отношение к поставке). В дефиниции метода нет ничего, связывающего его с программным обеспечением. Это метод управления, который может широко применяться в творческой интеллектуальной работе с концентрацией на организационные преобразования.
• Является ли канбан частью аджайл-движения? Принадлежность к канбан-сообществу наблюдается как внутри, так и за пределами аджайл-движения (обратите внимание на то, что оба сообщества имеют похожие отношения с сообществом бережливого производства). Похоже, что у некоторых людей такая неопределенность вызывает замешательство, на самом деле она полезна и даже необходима. Идеи имеют достаточно пространства для развития и реализации в своих сообществах, но в нужный момент открываются широкие возможности для взаимного обогащения. Что касается поставщиков сопутствующих услуг (тренеров, коучей, консультантов и т.д.), то им очень удобно иметь возможность выбирать клиентов, относящих себя к разным сообществам.

На уровне методов и практик:

• Подходит ли канбан для итерационных методов, в частности скрама? Да, и в этом случае скрам-комбинация даже имеет свое название — скрамбан (о ней говорится в главе 16). Канбан может использоваться как внутри скрама, где он, в основном, применяется для улучшения работы на уровне команды, так и вне его, где канбан помогает командной структуре справляться с проблемами масштаба.
• Означает ли использование канбана отказ от итераций и других элементов скрама? Это серьезное заблуждение. Канбан — это метод, основанный на принципе начните с того, что есть сейчас; мы первыми предупредили бы вас об опасности неконтролируемого отказа от части текущего рабочего процесса. Однако, с нашей стороны было бы нечестно притворяться, что стремление к поддержанию потока в какой-то момент станет испытанием вашей приверженности временны́м интервалам, пунктам истории и т.п. Как вы и ваша организация справитесь с этим — выбирать вам.
• Предоставляют ли методы и практики аджайла важные модели для пользователей канбана? Безусловно да — представляется почти немыслимым, что эффективный пользователь канбана, работающий в области разработки программного обеспечения, достигнет высоких результатов без глубокого понимания и уважения к аджайлу.

Когда применять канбан

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

• Продолжает ли принцип устойчивого темпа, являющийся элементом аджайла, оставаться мечтой? Перегружены ли люди в процессе, который, похоже, не всем подходит? Могут ли как-то помочь ценности канбана — прозрачность (глава 1) и баланс (глава 2)?
• Направлено ли сотрудничество (глава 3) преимущественно внутрь? Страдает ли клиентоориентированность (глава 4) из-за чрезмерной изоляции команды или чрезмерной внутренней концентрации на технологии, продукте или команде?
• Ориентированные на команду или на процесс подходы не справляются с задачей встраивания необходимых улучшений в сквозной поток (глава 5)? Ухудшают ли локальные выигрыши положение в целом?
• Не принижается ли значимость лидерства (глава 6), понимания (глава 7) и согласия? Можно ли сказать, что об уважении (глава 9) слишком легко забывают при принятии серьезных решений?

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

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

Модель аджайл

Не давайте ввести себя в заблуждение процессно-ориентированными трактовками FDD, XP и скрам. Вы можете применять эти методы раз за разом и по-прежнему считать, что:

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

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

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

Дополнительная литература

Рубин К. Основы Scrum. Практическое руководство по гибкой разработке ПО. — М.: Диалектика, 2020.

Хамбл Дж., Фарли Д. Непрерывное развертывание ПО: Автоматизация процессов сборки, тестирования и внедрения новых версий программ. — М.: Вильямс, 2016.

Manifesto for Agile Software Development ().

Ambler, Scott. Feature Driven Design (FDD) and Agile Modeling. .

Beck, Kent. 1999. Extreme Programming Explained: Embrace Change. Upper Saddle River, NJ: Addison-Wesley.

Schwaber, Ken and Jeff Sutherland. The Scrum Guide. .

Sheridan, Richard. 2013. Joy, Inc.: How We Built a Workplace People Love. New York: Portfolio Penguin.

Отправить