редакции
Два метода аджайла для эффективной разработки
В издательстве «Альпина Паблишер» вышла книга «Канбан Метод. Улучшение системы управления». Ее написал Майк Барроуз, известный канбан-коуч и главный консультант компании 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) движется в том же направлении. Автоматизированное приемочное тестирование включает в себя следующее: В этой области также много инноваций. Появились целые сообщества, которые формировались вокруг различных фреймворков и методов спецификации. Некоторые из них, в частности разработка через реализацию поведения (behavior-driven development — BDD), развились настолько, что сами превратились в методологии. Основанные на использовании открытого исходного кода распределенные системы управления версиями (distributed version control systems — DVCS), например git, позволяют сотням (если не тысячам) программистов участвовать в таких колоссальных проектах, как Linux, которая действительно является результатом совместной работы. Помимо прочего, эти инструменты продолжают формировать основу нескольких решений проблемы внедрения. Все чаще — и это просто превосходно для программистов вроде меня, занятых неполный рабочий день — их встраивают в хостинг-платформы. Теперь добраться до моего последнего творения в интернете можно также просто, как набрать команду git push в командной строке. Непрерывная поставка выжала из автоматизации управления кодами, тестирования и внедрения все возможное. Компании вроде Amazon сегодня выпускают релизы так часто, что средняя продолжительность интервала между ними измеряется секундами! С учетом того, что весь рабочий поток занимает всего лишь часы или дни, рабочие задачи в ХР должны быть небольшими и пригодными к тестированию. Считая функциональные требования, сценарии использования и наборы функций слишком громоздкими, экстремальное программирование популяризировало так называемые пользовательские истории — записанные на карточках требования к разрабатываемой системе, выраженные одним предложением, часто стереотипно («Как <пользователю> мне нужно <то-то и то-то>, чтобы получить <то-то и то-то>»). Все это также является предметом подробного исследования — на эту тему написаны целые книги. Читайте также: Почему планирование не работает и что с этим делать 5 лучших видео о бизнесе и маркетинге прошедшей недели Как искать работу в соцсетях: правила и примеры от автора «Пиши, сокращай» Маржинальность и стоимость переключения у продуктов: четыре понятных и простых варианта
Экстремальное программирование
«Если это причиняет боль, то делай это чаще и пусть она придет раньше»*.
