Артефакты agile

8.7 Рабочее пространство

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

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

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

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

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

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

Компании идут на распределенную разработку по разным причинам, разумным и не очень. Многие книги по agile предлагают адаптацию базисных моделей на случай распределенных команд. Они не обсуждаются в данной книге, поскольку я не нахожу в них общей ценности. Реальный вклад agile прямо противоположен: настаивая на необходимости прямого взаимодействия, аджилисты обращают внимание на эффективность в случае, когда все находятся в одном месте. Например, наиболее интересная часть книги Лармана [Larman 2010] об agile распределенной разработке – то ремарка в самом начале:

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

В течение десятилетия я принимал активное участие в успешной и устойчивой разработке проекта, выполняющегося командой из разных стран (Eiffel Studio в компании Eiffel Software). У меня есть успешный опыт чтения в ETH учебного курса по программной инженерии в распределенном варианте, когда студенты из университетов разных стран по всему миру участвовали в построении работающей программной системы. Тем не менее, могу утверждать, что наш опыт полностью подтверждает высказанное выше утверждение. Одно из первых предложений на первой лекции нашего курса:

"Основной закон распределенной разработки – не делайте этого!"

Когда есть выбор, то следует придерживаться этого принципа. Но иногда выбора нет. Аджилисты напоминают нам, что модель "все под одной крышей" является лучшей.

8.8 Бэклог продукта, бэклог итерации

Индивидуальные требования, как мы видели, покрываются пользовательскими историями.

Что можно сказать о требованиях как "о целом"? (В программной инженерии "требование" означает описание свойства системы, а "требования" – это не просто собрание отдельных требований, оно означает общее описание системы.) Подходы agile отрицают, конечно, традиционное понятие всеобъемлющего документа требований.

Заменой такого документа является собрание пользовательских историй или задач. Более точно:

• коллекция пользовательских историй, рассматриваемая как целое, представляет бэклог продукта;
• коллекция, выбранная для частной итерации, представляет бэклог итерации; в Scrum бэклог спринта составляет коллекция задач, ассоциированных с пользовательскими историями (каждая пользовательская история может порождать несколько элементарных задач).

Могут появляться и некоторые другие элементы. Кон приводит примеры "багов", технических работ, сбора информации.

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

• остаются нереализованными;
• находятся в стадии реализации;
• уже реализованы.

Некоторые команды вводят еще одну категорию: "должны быть проверены".

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

8.9 Карты историй, карты задач

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

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

(168 Поиск по имени

Как оператор доски помощи, я хочу искать моих потребителей по имени и фамилии, так чтобы время отклика оставалось коротким.)

увеличить изображение
Рис. 8.2. Пример карточки пользовательской истории

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

8.10 Панель задач и историй

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

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

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

увеличить изображение
Рис. 8.3. Панель историй. Бэклог спринта

Детали могут различаться. Метод Канбан был первым, где использовались подобные доски.

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

Панель задач – прекрасный способ фокусировать внимание команды на прогресс развития проекта, его скорость, особенно, когда доска дополняется диаграммой выполнения (burndown chart).

8.11 Выполнение и диаграмма выполнения

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

Рис. 8.4. Диаграмма выполнения (убывающая)

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

Вариант Кокбурна в методе Crystal использует возрастающую диаграмму выполнения (burnup chart), на которой по оси ординат откладываются баллы уже выполненных работ.

Общим для всех вариантов является правило, согласно которому учитываются только те работы, которые удовлетворяют двум условиям:

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

Рис. 8.5. Диаграмма выполнения (возрастающая)

И здесь предлагаются разнообразные программные средства ведения диаграммы.

Диаграммы выполнения являются важным практическим вкладом, позволяя команде отслеживать ежедневный ход развития проекта в красочной форме, понятной всем.

8.12 Помехи

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

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

8.13. Затраты, технический долг, зависимости, диаграммы зависимостей

Три последних обсуждаемых артефакта не принадлежат 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 подобен луддитам^{1Луддиты – работники, ломающие машины, чтобы сохранить ручное производство. Название произошло от ткачей, разбивающих ткацкие станки в попытках сохранить ручное ткачество.}. Нет причин для запрета в agile проектах использовать концепции и инструменты, помогающие справиться с проблемами. Составление расписания задач, совместимого с зависимостями между задачами, – проблема, с которой приходится сталкиваться лицом к лицу. Эффективный менеджер не считается с идеологией и использует все инструменты, помогающие в создании проекта.