Код – это центр agile мира, и главная ценность – это работающий код, который может быть выполнен как часть разработки системы. Акцент на коде является частью agile стремления уйти в программной инженерии от процессов и планов и перейти к конкретным результатам, которые только и важны для успеха программного проекта.
Наряду с кодом тесты – это главный продукт, рекомендуемый всеми agile подходами. Экстремальное программирование реабилитировало тесты, причисляя их к основной концепции программной инженерии. Два вида артефактов фактически входят в эту концепцию (позднее один из них стал коллекцией экземпляров другого): юнит тесты и набор регрессионных тестов.
Юнит тест представляет описание некоторого частичного теста и ожидаемых результатов его выполнения. Процесс юнит тестирования претерпел существенные изменения в связи с появлением инструменария тестирования, называемого xUnit, как например JUnit для Java. Как отмечалось в предыдущей главе, неслучайно, что Бек, одна из наиболее уважаемых личностей в XP, является (вместе с такими людьми, как Эрих Гамма) одним из авторов этого инструментария. Юнит тест в стиле xUnit принимает форму класса и включает:
age – возраст водителя; тест для этой операции может включать утверждение is_accepted implies (age >= 18 age <=75).Этот стандартный подход к определению тестов представляет одно из важнейших дотижений в искусстве программной инженерии за последние двадцать лет. Он применяется во многих проектах, даже в тех, что не используют agile методы.
Существует и лучший подход. Вместо того чтобы рассматривать код и тесты как отдельные артефакты и связывать утверждения только с тестами, можно рассматривать утверждения как механизм спецификации и записывать их как интегральную часть кода в форме инвариантов класса, предусловий и постусловий методов класса. Таким подходом является проектирование по контракту, используемое в языке Eiffel [Meyer 1997], [Meyer 2009]. При этом подходе появляется возможность автоматически генерировать тесты по коду и утверждениям. Все это, однако, предмет другого обсуждения.
Набор регрессионных тестов представляет коллекцию юнит тестов. Он включает любой тест, который в некоторой точке проекта не был успешно выполнен. Один из феноменов разработки ПО состоит в том, что "старые ошибки, уже исправленные, имеют тенденцию возвращаться на последующих шагах разработки". Причины различны: ошибки контроля версий, неполное устранение ошибки, чаще всего использование неудачного образца. Этот феномен называют регрессией. Одна из целей создания регрессионного набора тестов состоит в том, чтобы справиться с проблемой регрессии путем постоянного выполнения тестов как части непрерывной интеграции.
Фактически нет причин включать в этот набор только "падающие" тесты. Мы видели, что один из важных вкладов agile (прежде всего XP) – это правило, в соответствии с которым каждому элементу кода соответствует, по меньшей мере, один тест. XP требует, чтобы тест строился и запускался до реализации соответствующего кода, так что тест автоматически становится "падающим" и включается в регрессионный набор тестов. Амблер отмечает, что аджилисты ввели в практику если не TDD, то, по крайней мере, регрессионное тестирование.
Набор регрессионных тестов представляет один из определяющих agile артефактов, точно так же, как непрерывная интеграция – одна из определяющих agile практик, даже для команд, которые не воспринимают более экстремальные идеи, такие как TDD.
Регрессионный набор – ключевая ценность любого хорошо управляемого программного проекта. Частично его привлекательность в том, что он представляет истинно возрастающий продукт. Мы видели, что "возрастание", пропагандируемое в agile подходах, не всегда хорошо работает при применении к разработке. Но набор тестов обладает свойством "возрастания" по своей природе. Он может начинаться с совсем небольшого множества, и, если каждый придерживается дисциплины "ни пяди кода без теста", растет быстро и становится одним из основных ресурсов проекта.
Пользовательские истории составляют базисный набор требований в agile методах.
Пользовательская история представляет описание мелкозернистой функциональности, как ее видят пользователи. Более общим понятием является "случай использования" или "вариант использования", детально проработанный в хорошо известной книге Якобсона [Jacobson 1992]. Вариант использования может быть большим (крупнозернистым): он описывает сценарий полного взаимодействия, например, процесс заказа элемента на коммерческом сайте. Пользовательская история много меньше.
Стандартный стиль agile – описание пользовательских историй. В этом стиле пользовательская история задается тройкой: <роль, цель, преимущества>. Например:
"Как сотрудник Я хочу отменять заказы, так чтобы разумные запросы на исключение полисов можно было согласовывать".
Хотя некоторые проекты принимают такой фиксированный стиль, возможны различные варианты описания.
Определяющее свойство пользовательских историй как средства для описания функциональности системы в том, что каждая история описывает единицу функциональности с точки зрения пользователя, более точно с позиций роли пользователя, поскольку есть понятие роли, но нет понятия просто "пользователь". "Сменить реляционную базу данных на не-SQL решение" – это не пользовательская история. Для интеграции такого ахитектурного решения необходимо определить его как задачу для пользовательской истории, которая описывает преимущества, видимые пользователю. Например:
"Как менеджер по маркетингу Я хочу создать новые предложения потребителям без соответствия существующим схемам, так чтобы была возможность более быстро отвечать потребностям рынка".
Преимущества, связанные с пользовательскими историями как основой разработки, в том, что команда ориентируется на преимущества, доставляемые системой пользователю, а не зацикливается на внутренних потребностях самой системы. Но в этом огромном преимуществе одновременно кроется и дефектность такого подхода. Размер пользовательской истории, как следует из определения, оставляет мало простора для догадок. Рассмотрим два примера, каждый из которых добавляет функцию в систему покупки билетов на самолет.
История 2 инспирирована ситуацией, рассказанной Поппендик, в которой компания нарушила Lean принцип "целостности", предоставив две различные системы для покупки билета и покупки, оплачиваемой за счет накопленных миль.
Эти две истории внешне похожи, но существенно различаются по сложности. Реализация истории 1 представляет рутинную задачу, на которую потребуется максимум один день работы. Предполагая, что две системы продажи билетов (за наличные и за счет компенсации за накопленные мили) различаются, как в ситуации, рассказанной Поппендик, реализация истории 2 потребует слияния двух систем. Реализация слияния двух систем требует значительных усилий. Это обычная ситуация – разные истории требуют разных усилий для их реализации, что приводит к необходимости вводить оценку сложности историй, измеряемую в баллах. Тема сложности будет обсуждаться в следующем разделе. Сейчас же поговорим об усилиях разного типа. Одни усилия носят характер возрастающего усовершенствования, другие – хирургического вмешательства. Специфицирование двух различных по характеру задач в одной и той же форме пользовательских историй скрывает их принципиально различную природу. Историю 2 лучше явно специфицировать как изменение архитектурного решения, даже если не будет указано, какие преимущества принесет это решение конкретному пользователю.
Отсутствие такой перспективы может привести к нестабильным проектам и бесполезной работе. Каждый может представить существование пользовательских историй, говорящих о необходимости заказа билетов за счет компенсации накопленных миль. Реализация этих историй может приводить к созданию отдельной системы. Могут появляться новые истории, и в какой-то момент окажется, что эта система становится столь же сложной, как и обычная система покупки билетов. Естественно возникнет вопрос о слиянии систем. Правильный подход, позволяющий избежать дублирования и напрасных затрат, мог бы быть основан на архитектурном предвидении и осознании на ранних этапах, что авиакомпания должна иметь модель предметной области, покрывающей все концепции резервирования билетов. Обе рассматриваемые системы покупки в этом случае имели бы в основании одну и ту же модель. Такой подход требует абстрагирования от индивидуальных пользовательских историй, требует некоторого системного видения ситуации, концентрации на фундаментальных свойствах системы. Все это приводит к необходимости вначале разрабатывать архитектуру, прежде всего модель предметной области. Эта модель будет поддерживать различные пользовательские истории, предвиденные изначально, и те, что появятся позднее.
Кстати, все сказанное вполне сочетается с одним из принципов agile подхода Lean – "Видеть Целое". Но Поппендик не показывает, как этот принцип может сочетаться с разработкой, полностью основанной на пользовательских историях. Он не сочетается.
Вынесение пользовательских историй на передний план является важным вкладом agile. Они играют важную роль, но не ту, что им отводит agile. В качестве основы разработки они приводят к системе, сшиваемой из кусочков, к системе, где одна функция добавляется за другой без должного внимания к инфраструктуре в целом. Правда, работы по созданию инфраструктуры не приносят славы, в agile подходах их пытаются отодвинуть в сторону, поскольку они не приносят пользователю немедленных видимых преимуществ. Замена реляционной базы данных на не-SQL решение не добавляет функциональности, но может быть критичной с позиций расширяемости и масштабирования системы. Замена структуры данных, основанной на деревьях, структурой, основанной на хэш-таблицах, вещь загадочная для потребителей, заставляющая их гадать, "а чем это занимаются разработчики уже вторую неделю"? Здесь нет никаких пользовательских историй, и все же это может быть ключевым решением для проекта в целом.
Точно так же, как тест, даже миллионы тестов, не могут заменить спецификацию, пользовательские истории (и варианты использования) не могут заменить требования и проектирование архитектуры. Уникальная роль историй, аналогичная роли тестов для спецификаций, состоит в том, что они обеспечивают механизм проверки правильности требований и проектирования. Требования высокого уровня имеют преимущества абстракции и общности, но несут риск непрактичности, пропуска случаев, важных для пользователя. Составление списка пользовательских историй не должно заменять написание общих требований, но это важный шаг в понимании того, что ничто важное не забыто. Они позволяют проводить сквозной контроль, недостаточный для полного описания системы, но необходимый для ее успешной работы.
Одного из моих коллег однажды попросили проконсультировать архитектуру забавного нового компьютера, полную новых концепций, объектно-ориентированную и так далее. После прослушивания с энтузиазмом представленной презентации его первой реакцией было: "Очень впечатляюще, спасибо, но как я должен загружать и хранить данные?" Ему не хватало типичных пользовательских историй. Как тесты предлагаемой системы они незначимы. Как способ построения системы (кто будет конструировать архитектуру компьютера на основе загрузки и хранения?) они недостаточны. Тем не менее, они важны.
Придавая пользовательским историям слишком большое значение, мы умаляем роль задач, критичных для всех применений, для того рода деятельности, которая является предметом критики со стороны agile, – построение модели предметной области. Эта модель (в предположении объектно-ориентированной разработки) представляет множество классов, покрывающих фундаментальные концепции создаваемой системы: полеты и накопленные мили, служащие и квитанции, клиенты и кредитные карты, абзацы и шрифты, телефонные вызовы и текстовые сообщения. Эти и другие концепции проектируются с ассоциированными операциями, отношениями между классами – наследованием, клиент–поставщик. При проектировании предметной области внимание уделяется в первую очередь бизнес-аспектам системы, а не только аспектам, носящим чисто программный характер, – доступу к базам данных и пользовательским интерфейсам. Построенная в результате модель предметной области не задает функциональность, поставляемую пользователю. И все же эта модель представляет прочный скелет, позволяющий успешно развивать систему.
Можно перестараться и иметь "слишком много хороших вещей". Существует риск проектирования системы "на все времена", пренебрегая тем, что пользователям нужна видимая функциональность. И это в тот момент, когда должны появиться пользовательские истории, осуществляющие проверку на реальность. Техника дуального программирования, обсуждаемая в предыдущей главе (7.4), играет здесь важную роль, позволяя организовать нужную смесь двух подходов двумя разными способами:
Основываться исключительно на пользовательских историях как на источнике требований недостаточно для построения прочного базиса системы. Такой узкий взгляд является одним из главных ограничений agile методов.
Успешный контроль проекта требует как оценки затрат на разработку до начала итерации, так и измерения прогресса в период выполнения и в конце итерации.
Мы рассматривали приемы оценивания при обсуждении игры в планирование и покер планирования (6.3 и 6.4). Точно так же важно проводить измерение того, что сделано в процессе развития проекта.
При проведении как оценок, так и измерений необходимо выбрать единицу измерений. Артефакты в этом и следующем разделах представляют ответ agile на этот вопрос.
Традиционно в программной инженерии такой единицей является человеко-месяц или человеко-день. Эта мера хороша для бухгалтеров, рассчитывающих зарплату и определяющих затраты ИТ, но как метрика эффективности проекта она не столь полезна. Помимо знания того, сколько времени было затрачено, мы хотим знать, что же достигнуто при этих временных затратах. (Всякий, кто когда-либо имел дело с родителями студента, рассказывающими "как много и упорно работал студент и почему же у него плохая оценка", понимает, в чем разница.)
В качестве меры все еще широко используется подсчет числа строк заключительного кода. Число строк нетрудно подсчитать, но, кажется, это единственный аргумент в пользу такой меры. Даже если предположить, что это хороший показатель функциональности (спорное утверждение), трудно представить, как можно заранее подсчитать этот показатель для будущей системы. Показатель неудобен и для измерения прогресса разработки. (Спасибо, что вы мне сказали, что уже произвели 85 000 строк, но значит ли это, что работа выполнена на 90 %, 50 % или сделано только 10 % работы.)
Обычно, лучшей мерой является число функций, разработанных при создании системы. Но это число трудно оценить заранее, и оно не всегда подходит при применении современной объектно-ориентированной технологии разработки, где абстракция данных так же важна, как и методы обработки данных.
В мире agile основой для измерения прогресса разработки естественным образом стал принятый способ измерения функциональности – пользовательские истории. Понятно, что не следует просто подсчитывать число историй: история истории рознь. Поэтому возникло понятие оценки истории – число баллов, начисляемое истории, характеризующее ее сложность.
Единицей может служить день работы, но могут быть и другие критерии. Например, за единицу можно принять простейшую историю, тогда все остальные будут оцениваться относительно этой базисной истории. По словам Кона [Cohn 2006]:
Красота в том, что оценивание историй в баллах полностью отделяет оценивание трудоемкости разработки от оценивания ее длительности. Конечно, трудоемкость и расписание коррелированы между собой, но их разделение позволяет оценить каждый показатель независимо. Фактически вы более не оцениваете длительность проекта: она автоматически выводится из числа итераций, затрачиваемых на реализацию принятых историй.
Кон говорит об априорном оценивании проекта, но сказанное применимо и к апостериорным измерениям.
Баллы истории имеют следующие важные свойства.
Более общий взгляд: любой непоставляемый артефакт не учитывается при оценке прогресса проекта. Примеры могут включать документацию, планы, требования – все, что с точки зрения agile представляет "затраты", хотя такие артефакты могут учитываться, если они явно входят в определение "сделано", что будет обсуждаться далее. Заметьте, тесты, которые по определению не являются "затратами", не учитываются в баллах истории.
Баллы истории являются относительно недавним добавлением в коллекцию agile артефактов. Экстремальное программирование вначале использовало абсолютное измерение времени – идеальное время программирования, то есть число дней, требуемых для реализации истории при условии полного рабочего дня и отсутствия помех. Помимо этого, вводился "коэффициент устойчивости", позволяющий оценить реальное время путем умножения идеального времени на коэффициент, который типично принимался от 2 до 4 (Бек). Критики говорили, что введение коэффициента устойчивости на практике означает некоторую фальсификацию оценок, но на самом деле это очевидное стремление расширить рамки оценок. В 2002 году XP перешел к "чистым программистским неделям". Это тренд, указывающий на стремление уйти от точных временных единиц к цифрам, не носящим абсолютный характер. Чтобы подчеркнуть это свойство, иногда применяется термин "резиновый мишка" как синоним "баллы истории".
Внутри проекта баллы истории имеют смысл, поскольку позволяют сравнивать прогресс от одной итерации к следующей в согласованных единицах. И снова Кон [Cohn 2006]:
Здесь нет формул, устанавливающих размер истории. Оценка истории в баллах отражает трудоемкость разработки функционала, сложность разработки, риск, присущий истории.
Покер планирования (как и более ранний вариант – игра в планирование) – один из принятых в agile приемов для получения таких оценок. Вы помните, что в покере используется набор значений, взятый из некоторой последовательности чисел, например из последовательности чисел Фибоначчи: 0, 1, 2, 3, 5, 8… При такой практике 1 означает историю минимальной стоимости, и все другие значения соизмеряются с ней. Вы можете полагать, что эта минимальная история требует двух часов или половины дня работы, хотя, как поясняет Кон, точный выбор для этого соответствия для оценки процесса не критичен.
Сразу же, как пользовательским историям даны индивидуальные оценки и итерация началась, те же самые меры могут служить для оценки прогресса разработки. Здесь становится полезным понятие "скорость".
Это понятие, критически важное и, на удивление, часто игнорируемое в период до agile, дает четкую, измеримую, непрерывную оценку скорости развития проекта.
Среди программистов ходит много шуток о проектах, готовых через несколько недель после их начала на 90 % и остающихся в этом состоянии в течение длительного времени. Но вопрос "как далеко вы продвинулись" вполне уместен для менеджеров и других сопричастников проекта.
Скорость является синонимом быстроты, то есть как быстро выполняется работа. Для движущихся объектов скорость $$V$$ задается отношением $$S/t$$, где $$S$$ – пройденный путь, а $$t$$ – время его прохождения. Эта интерпретация применима и к скорости разработки проекта. Числитель измеряется в баллах историй, знаменатель явно не появляется, поскольку он принимается равным единице – одной итерации (спринт в Scrum). Так что под скоростью в agile мире понимается число баллов тех историй, которые выполнены во время итерации.
Так, определенная скорость дает меру выполненных работ. Эта концепция подтверждает справедливость выбора относительных оценок, а не абсолютных. В начале работ над проектом довольно трудно сказать, сколько времени уйдет на реализацию задачи – два часа или целый день. Оценивание в баллах позволяет избежать задания точных временных оценок и сосредоточиться на оценке относительной сложности задач, сравнивая их друг с другом. Если применять эту методику согласованно в течение всего проекта, то относительные предсказания (баллы истории) будут все более приближаться к абсолютным значениям (длительности выполнения истории).
Конкретно предположим, что у нас есть две оценки:
По нашим ожиданиям, второе из этих предположений может быть дальше от истины, чем первое. Теперь предположим, что в течение 30-дневного спринта удалось выполнить историй на 20 баллов. Предположим, что подобная ситуация имела место и в течение последующих нескольких спринтов (вспомните "коэффициент устойчивости" в ранних версиях XP), так что нужно полагать, что знаменатель, определяющий время при подсчете скорости, равен не 1, а 1,5. Если с течением времени этот образец остается стабильным и команда работает все лучше, как и должно быть, то оценки становятся все более точными. Это та "красота", которую имел в виду Кон в приведенной выше цитате.
(рис 8.1) Оценка трудоемкости разработки. Конус неопределенности
Такие приемы, которые используют непрерывно уточняющиеся измерения для улучшения первоначальных грубых оценок, являются примером более общей концепции программной инженерии, первоначально введенной Боемом [Boehm 1981] и получившей название "конус неопределенности". Конус определяет границы (в конечном счете – измеряемое значение) некоторого свойства проекта. В ходе работы над проектом мы имеем все больше информации о свойстве проекта, и границы сужаются.
Как отмечалось, скорость обычно измеряется по отношению к полной итерации. Иногда может быть полезен более мелкий уровень гранулярности. Хотя вряд ли имеет смысл сравнивать вчерашнюю и сегодняшнюю скорость, но построение непрерывного графика скорости может служить хорошим индикатором развития проекта.
Скорость – одна из наиболее интересных концепций, популяризируемых agile методами. К метрике, основанной на баллах историй, как единой мере трудоемкости проекта, можно предъявлять претензии. Они были высказаны в начале этой главы. Тем не менее, утверждение, что проект должен следить и визуализировать скорость развития, является полезным и впечатляющим.
Акцент agile на поставку актуальной функциональности, избегая затрат, отражается в строгом определении прогресса как числа баллов поставленных историй, но это требует строгих и согласованных критериев, устанавливающих, что задача действительно сделана. В Scrum дается определение понятия "сделано", объясняющее, что мы имеем в виду, когда говорим – это "сделано".
Согласованность крайне важна в определении "сделано". Мы можем требовать или не требовать, чтобы полнота пользовательской истории включала полноту соответствующих данных, вводимых пользователем вручную, но принятие такого решения должно быть единым для всех пользовательских историй. В противном случае мы не сможем правильно оценивать меру прогресса разработки.
Сазерленд [Sutherland 2013] приводит следующие определения "сделано":
Технический долг – понятие, означающее несовершенство кода или изъяны в архитектуре, которые в будущем, возможно, потребуют неоправданной работы.
Экстремальное программирование приводит доводы в пользу размещения программистов в открытом пространстве без физического разделения, которое иногда называют "загоном для скота", как способ поощрения коммуникации. Бек пишет:
XP хочет подстраховаться, предоставляя довольно много публичного пространства. XP является коммунальной разработкой. Члены команды должны видеть друг друга, слышать вопросы, обсуждаемые рядом, чтобы "случайно" вмешаться в беседу, что может оказаться существенно важным.
Эта идея широко принята другими agile подходами, так что без преувеличения можно заменить XP на "agile методы" в рассуждениях Бека.
Коммунальное пространство не исключает возможности приватности в случае необходимости. Рекомендация Бека также включает наличие индивидуальных кабинок рядом с коммунальным пространством, так что члены команды могут хранить свои личные материалы, уединяться при телефонных переговорах, проводить там время, когда они не хотят, чтобы их работа могла быть прервана. Остальные члены команды должны с уважением относиться к "виртуальной" приватности каждого, уединившегося в своей кабине.
В описании метода Crystall Кокбурн также уделяет большое внимание организации офиса, способствующей "осмотической коммуникации", когда вас подталкивают к общению.
Хотя каждому известно, что практичная организация офиса оказывает влияние на эффективность работы команды, не следует преувеличивать роль комфорта для программистов. Многие из наиболее успешных проектов Силиконовой долины начинались в гаражах. Наиболее интересным вкладом agile по этому вопросу является предположение, что офис должен быть местом работы всей команды. Это предположение не может гарантироваться, поскольку все больше и больше проектов становятся распределенными.
Компании идут на распределенную разработку по разным причинам, разумным и не очень. Многие книги по agile предлагают адаптацию базисных моделей на случай распределенных команд. Они не обсуждаются в данной книге, поскольку я не нахожу в них общей ценности. Реальный вклад agile прямо противоположен: настаивая на необходимости прямого взаимодействия, аджилисты обращают внимание на эффективность в случае, когда все находятся в одном месте. Например, наиболее интересная часть книги Лармана [Larman 2010] об agile распределенной разработке – то ремарка в самом начале:
Эксперт по разработке Дон Рейнертсен рассказал нам, что он неформально опросил тысячи людей за последнее десятилетие и не нашел ни одной группы, имеющей практический опыт как совместной работы, так и распределенной, которые бы снова выбрали распределенную разработку.
В течение десятилетия я принимал активное участие в успешной и устойчивой разработке проекта, выполняющегося командой из разных стран (Eiffel Studio в компании Eiffel Software). У меня есть успешный опыт чтения в ETH учебного курса по программной инженерии в распределенном варианте, когда студенты из университетов разных стран по всему миру участвовали в построении работающей программной системы. Тем не менее, могу утверждать, что наш опыт полностью подтверждает высказанное выше утверждение. Одно из первых предложений на первой лекции нашего курса:
"Основной закон распределенной разработки – не делайте этого!"
Когда есть выбор, то следует придерживаться этого принципа. Но иногда выбора нет. Аджилисты напоминают нам, что модель "все под одной крышей" является лучшей.
Индивидуальные требования, как мы видели, покрываются пользовательскими историями.
Что можно сказать о требованиях как "о целом"? (В программной инженерии "требование" означает описание свойства системы, а "требования" – это не просто собрание отдельных требований, оно означает общее описание системы.) Подходы agile отрицают, конечно, традиционное понятие всеобъемлющего документа требований.
Заменой такого документа является собрание пользовательских историй или задач. Более точно:
Могут появляться и некоторые другие элементы. Кон приводит примеры "багов", технических работ, сбора информации.
Термин "бэклог" отражает особый способ использования этой коллекции. Практика, ассоциируемая со Scrum, но широко используемая, разделяет бэклог на три части, содержащие соответственно пользовательские истории или задачи, которые
Некоторые команды вводят еще одну категорию: "должны быть проверены".
Полезно визуализировать бэклоги. Артефакты в следующих трех разделах служат этой цели.
От средств концептуальной природы перейдем к рассмотрению вещественных, зримых артефактов.
Систематическое использование пользовательских историй как единиц требований приводит к необходимости стандартизации формы их записи. Технически простые версии используют "карточки историй" – стандартного размера бумажные карточки, на каждой из которых записана история, как показано на типичном примере:
(168 Поиск по имени
Как оператор доски помощи, я хочу искать моих потребителей по имени и фамилии, так чтобы время отклика оставалось коротким.)
(рис 8.2) Пример карточки пользовательской истории
Многочисленные рыночные инструменты предоставляют электронные эквиваленты бумажных карточек, хотя по-прежнему многие предпочитают бумажный вариант.
При постоянном внимании, уделяемом скорости разработки – поставке лучших потребительских ценностей в самые короткие сроки, для agile подходов становится важным постоянное информирование команды о том, что уже сделано, что находится в процессе разработки и что еще предстоит реализовать. Визуализация такой информации помогает нескольким agile целям, в частности:
Для визуализации обычно используют панель или доску с колонками, представляющими возможные состояния задач. Как отмечалось ранее, могут быть состояния "необходимо выполнить", "в процессе разработки", "в процессе тестирования", "сделано". Наиболее часто используется доска, в каждую колонку которой прикрепляются карточки задач, передвигаемые слева направо в процессе реализации задач.
(рис 8.3) Панель историй. Бэклог спринта
Детали могут различаться. Метод Канбан был первым, где использовались подобные доски.
Разнообразные программные средства позволяют заменять этот физический артефакт. В частности, они естественно используются для распределенных команд. Но для команд, работающих в одном месте, трудно победить простоту и визуальное воздействие обычной доски с бумажными карточками и их физическим перемещением.
Панель задач – прекрасный способ фокусировать внимание команды на прогресс развития проекта, его скорость, особенно, когда доска дополняется диаграммой выполнения (burndown chart).
Убывающая диаграмма выполнения (burndown) дает визуальное представление прогресса команды – скорости разработки. Идея, представленная в обзорной главе, проста: строится график, на котором для каждого дня с начала выполнения итерации отмечаются оставшиеся для выполнения задачи. Ось абсцисс этого графика обычно задает время в днях, ось ординат – суммарное число баллов еще не реализованных задач (могут применяться и другие подобные меры).
(рис 8.4) Диаграмма выполнения (убывающая)
На диаграмме всегда показана прямая линия, соединяющая две точки: начало итерации, когда еще ни одна задача не выполнена, и заключительный день, когда все задачи должны быть выполнены. Эта прямая соответствует идеальному графику работы с постоянной скоростью, когда все работы заканчиваются в точно назначенный срок. Ежедневно строящаяся кривая показывает, насколько успешно или неуспешно развивается проект. Если текущая точка графика выше прямой, это свидетельствует об отставании, если ниже, значит, работы ведутся с опережением.
Вариант Кокбурна в методе Crystal использует возрастающую диаграмму выполнения (burnup chart), на которой по оси ординат откладываются баллы уже выполненных работ.
Общим для всех вариантов является правило, согласно которому учитываются только те работы, которые удовлетворяют двум условиям:
(рис 8.5) Диаграмма выполнения (возрастающая)
И здесь предлагаются разнообразные программные средства ведения диаграммы.
Диаграммы выполнения являются важным практическим вкладом, позволяя команде отслеживать ежедневный ход развития проекта в красочной форме, понятной всем.
Мы уже видели, что постоянной заботой в Scrum, в частности, главной задачей Scrum-мастера, является устранение помех. В соответствии с определением, помехой является все, что вредит прогрессу проекта, будь то техническая или организационная причина. Типичными помехами являются отсутствие необходимого оборудования, необходимого модуля, который должен быть поставлен другой командой, отрицательные внешние влияния.
Понятие скорости позволяет дать более точное определение: помеха – это любой фактор, снижающий скорость.
Три последних обсуждаемых артефакта не принадлежат agile подходам, но они принадлежат дискуссиям agile, где отмечается их негативная роль, как то, чего следует избегать.
Затраты и борьба с ними находятся в центре метода Lean. На этом сосредоточены и другие agile методы. Затраты не представляют некий единый артефакт, а включают продукты, материалы – все, что не поставляется пользователю. Документ проектирования является затратой, как и встречи, не фокусированные на задачах пользователей. Настаивание agile на том, что только код и тесты являются продуктами, заслуживающими рассмотрения, ведет к тому, что затраты принимают различные формы, с которыми agile команды должны бороться.
Технический долг – это те элементы кода или архитектуры, качество которых признается неудовлетворительным. До некоторого момента эти элементы могут присутствовать в проекте без особого вреда для него. Ситуация напоминает ракушек, прилипающих к днищу корабля. Когда их мало, они практически не влияют на скорость корабля, но когда их масса возрастает, это может привести к полной потере хода. Принципиальным agile средством борьбы с техническим долгом является рефакторинг, в задачу которого входят обнаружение и удаление "плохо пахнущих" участков кода и архитектуры.
Зависимости – это ограничения между элементами разработки, такими как задачи или пользовательские истории, отражающие тот факт, что при разработке элемента В требуется, чтобы была завершена разработка элемента А. В проекте компилятора, например, В может "реализовать парсер", а А – "специфицировать интерфейс лексического анализатора". Зависимости влияют на способ выбора очередной задачи из списка бэклога и назначения ее освободившемуся разработчику в кроссфункциональной команде, где задачи упорядочены в соответствии с их бизнес-ценностью. Очевидно, что если В зависит от А, но имеет более высокую бизнес-ценность, то нельзя применять принятую стратегию выбора по бизнес-ценности. Отсюда, естественно, следует agile рекомендация минимизировать число зависимостей – достойная цель, которую легко провозгласить и которой трудно достичь.
Обсуждение взаимодействия функций системы показывает, насколько сложно они могут быть взаимосвязаны. Этот феномен – одна из причин, по которой реально нельзя надеяться на избавление от зависимостей.
Еще одно препятствие для политики agile распределения работ – существование разработчиков. Разработчик разработчику рознь, ведь не все команды являются кроссфункциональными. Если следующую задачу, имеющую наивысшую степень бизнес-значимости, наиболее компетентно и быстро может реализовать вполне конкретный член команды, который в этот момент еще занят, то лучше дождаться момента его освобождения и поручить эту задачу ему.
Затраты, технические долги, зависимости являются виртуальными понятиями. Последний элемент в этом списке осуждаемых agile понятий может иметь физическое представление, хотя он часто используется и как чисто виртуальный артефакт. Речь идет о диаграмме зависимостей, часто принимающей форму, вызывающую особое презрение аджилистов, – о диаграмме Ганта, которая является одним из основных средств такого инструмента управления проектами, как Microsoft Project. Базисный способ использования таких диаграмм и инструментария (в традиционно управляемом проекте) прост:
Типичная для agile критика диаграмм Ганта высказана Коном [Cohn 2003]:
Вместо детального командного плана управления, основанного на диаграммах Ганта, планирование в agile базируется на инвестиционном видении, когда менеджмент может оценить и часто скорректировать инвестиции, изложить общее множество договоренностей, вытекающих из непредвиденных обстоятельств, адаптации, сотрудничества и устанавливающих ожидания, которые могут быть измерены в ходе разработки.
(рис 8.6) Диаграмма Ганта управления проектом
Обратите внимание на обвинительную характеристику диаграммы Ганта: "командный план управления" и расплывчатость предлагаемой замены. Кокбурн предлагает конкретную замену:
Организация может адаптировать некоторые из идей (метода Crystal) для упрощения или улучшения их работы (замена диаграмм Ганта на диаграммы "заработанной ценности" или "возрастающей диаграммы выполнения" было бы хорошим началом).
Возрастающие и убывающие диаграммы выполнения рассмотрены выше. Диаграммы "заработанной ценности" являются ранней формой, не имеющей программной специфики.
Предложение удивительно, поскольку диаграммы выполнения позволяют следить за прогрессом проекта, но мало помогают в его планировании.
Быть всегда начеку относительно затрат, обнаруживать и устранять технические долги, минимизировать долги – все это достойные цели. Причудливый поворот в agile подходе возникает, когда во имя этих целей отрицаются диаграммы Ганта и средства планирования, исходящие из зависимостей. Хотя Microsoft Project сам по себе не является выдающимся продуктом 21 века (и возраст солидный и тяжел в использовании), использовать его здесь в качестве "красной тряпки" не стоило бы, поскольку существует масса современных средств эффективного управления зависимостями; многие из них доступны в облаке. В любом сложном проекте существуют зависимости. Некоторые из них трудноуловимы, но, в конечном счете, более важны, поскольку их позднее обнаружение повредит развитию проекта. Можно пытаться минимизировать зависимости, но (как отмечают сами agile авторы, по крайней мере, в печати) их нельзя исключить. Диаграммы Ганта и другие подобные механизмы являются мощными инженерными инструментами, входящими в набор инструментов современного разработчика. Отказ от них или игнорирование их существования приводит к необходимости управлять ими вручную, что утомительно и чревато ошибками. Зависимости отомстят, когда реализацию задачи придется приостановить, поскольку не сделана другая задача, вырабатывающая нужные нам результаты.
Здесь agile подобен луддитам
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.