Два метода аджайла для эффективной разработки

В издательстве «Альпина Паблишер» вышла книга «Канбан Метод. Улучшение системы управления». Ее написал Майк Барроуз, известный канбан-коуч и главный консультант компании David J Anderson and Associates. Spark публикует отрывок из новой книги, посвященный моделям организации процесса разработки.

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

Джефф Делюка создал методологию функционально-ориентированной разработки (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 сегодня выпускают релизы так часто, что средняя продолжительность интервала между ними измеряется секундами!

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

Читайте также:

Почему планирование не работает и что с этим делать

5 лучших видео о бизнесе и маркетинге прошедшей недели

Как искать работу в соцсетях: правила и примеры от автора «Пиши, сокращай»

Маржинальность и стоимость переключения у продуктов: четыре понятных и простых варианта