Практики agile: производственные процессы

6.1 Sprint

Один из основных принципов agile требует итеративной разработки и частых поставок. Все agile методы применяют эту идею, различаясь в предписаниях длительности итераций. Для обозначения этих итераций широко используется термин, введенный Scrum, – спринт (sprint).

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

6.1.1 Основы sprint

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

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

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

6.1.2 Правило закрытого окна

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

Это правило позволяет справиться с одной из важных помех на пути успешной разработки – пагубным разрастанием свойств. Если быть более точным, то правило позволяет бороться с заказчиками и менеджерами, индуцирующими разрастание свойств. Заказчики и менеджеры полны идеями и мечтают о новых и новых свойствах. Демонстрация им системы на начальных этапах работы (что само по себе неплохо и усиленно пропагандируется в agile) стимулирует процесс добавления новых свойств, поскольку демонстрация явно показывает, какая функциональность опущена. Сам по себе феномен разрастания свойств неизбежен и во многих отношениях полезен. Успешная система хорошо служит бизнесу, если ключевые игроки сказали свое слово. Проблема пагубного разрастания часто возникает из-за людей, в чьей власти изменять приоритеты. Он или она приходят с суперидеей, настолько "супер", что ее следует реализовать немедленно в ущерб текущим задачам. Такие прерывания могут быстро свернуть проект с правильного пути: приоритеты меняются, важные работы задерживаются, разработчики деморализуются. Но без четкого процесса управления изменениями такие запросы трудно игнорировать по политическим соображениям.

Гениальность правила закрытого окна в том, что разрастание свойств не игнорируется, не делаются попытки сражаться с ним в открытую. Все направляется в строго лимитированное русло планирования очередного спринта. Практическим следствием является естественный отбор конкурирующих свойств. По прошествии нескольких дней многие великолепные предложения теряют свой блеск. Когда приходит время отбора задач на следующий спринт, они уже не кажутся столь неотложными. Удается избежать срывов, и шум затихает сам по себе. Идеи, истинно заслуживающие рассмотрения, получают приоритет по отношению к другим задачам.

6.2 Ежедневные встречи

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

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

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

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

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

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

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

• Время встречи. Как правило, 15 минут недостаточно. Даже при хорошем оборудовании и подготовленной группе минуты тратятся на не относящиеся к делу переговоры: "Как вы меня слышите? Давайте переключимся со Skype на Web Ex. Комната для видеоконференции все еще занята".
• Гибкое рабочее расписание. Во многих организациях служащие приходят в разное время и иногда остаются работать дома. Такая практика противоречит требованию agile прямых персональных контактов, но у нее есть свое оправдание – желание выдерживать устойчивый темп, и компании вынуждены с этим соглашаться.
• Временные зоны. Рассмотрим группу, одни члены которой находятся в Калифорнии, а другие – в Шанхае. 7 утра (зимой) для одних, 11 вечера – для других. Можно попросить быть на встрече без опозданий, но не каждый день.
• Переносы встреч. В то время, когда есть хорошие причины переносить технические обсуждения на отдельные встречи, следует думать и о сложностях организации встреч. (Давайте обсудим этот вопрос во вторник. – Во вторник меня не будет, может быть, в среду в 10? – Я думаю, что переговорная будет занята.) Иногда, когда проблему можно решить в течение 20 минут, проще решить ее здесь и сейчас.
• Вариация длительности. Нет причин всегда использовать встречи постоянной длительности вне зависимости от размера команды. Для команды в пять человек достаточно 15 минут, для команды из десяти человек этого явно недостаточно.

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

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

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

6.3 Игра в планирование

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

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

Игра в планирование в XP не является "игрой", носящей характер соревнования, где есть победители и проигравшие. Она соответствует кооперативным играм теории игр, где два игрока пытаются достичь максимизации различных критериев и ищут компромисс между ними. Двумя игроками в данном случае являются "бизнес" и "разработка" в терминах Бека, или проще – потребители и разработчики. Потребители пытаются максимизировать функциональность и минимизировать время ее достижения. Разработчики оценивают уровень трудности, связанный с каждым элементом функциональности, и требуемое для реализации время, которое невозможно сократить. В этой игре

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

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

6.4 Покер планирования

Покер планирования в Scrum играет ту же роль, что и игра в планирование в XP. Его задача – заранее оценить стоимость пользовательских историй. И снова обсуждение не зависит от меры стоимости: то ли это человеко-дни, то ли баллы, начисляемые истории.

В покере планирования используются две идеи:

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

В качестве такого множества обычно выбираются числа Фибоначчи: 0, 1, (снова 1) 2, 3, 5, 8, 13, 21, 35,…

Я уже слышу ваши возгласы: "Это не числа Фибоначчи! Последнее число должно быть 34!" Действительно. Поздравляю вас с хорошей математической подготовкой. Но в нашем случае все разумно и изменение имеет свою причину. Один известный agile консультант организовал блестящий бизнес по производству и продаже колод карт для покера в Scrum. Чтобы не иметь проблем с правами на использование чисел Фибоначчи, он слегка изменил последовательность. Напомню, что числа Фибоначчи были предложены итальянским ученым Фибоначчи в 1202 году (в Индии они появились тысячелетием ранее). Для Scrum покера не имеет особого смысла давать точную оценку, поэтому и 34, и 35 одинаково хороши.

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

Некоторые варианты планирующего покера в качестве множества оценок выбирают еще меньшие множества, например множество из 5 оценок, соответствующих размеру некоторых видов одежды от X small до X large. Многие варианты включают в это множество и значение, задаваемое знаком вопроса (?), применяемое, когда член команды затрудняется оценить стоимость рассматриваемого элемента, не имея достаточной информации.

Панель оценок, используемая в покере, заполняется командой разработчиков, но в обсуждениях участвуют владелец продукта и представители потребителей. Работа по оцениванию строится в форме "Delphi" – метода принятия решения, основанного на достижении консенсуса экспертов. Этот метод десятилетиями применялся в вооруженных силах США. Он также отвечает более современной концепции "мудрости толпы", в соответствии с которой группа в среднем может коллективно достичь лучшего решения, чем решение, данное лучшим индивидуальным экспертом. Целью метода является достижение консенсуса, но при этом следует избегать возможности подавления мнения меньшинства.

Процесс оценки стоимости элемента функциональности включает следующие шаги:

1. Кто-то, обычно владелец продукта, описывает функциональность.
2. Участники обсуждают ее и задают по необходимости вопросы.
3. Каждый участник индивидуально оценивает элемент, давая одну из используемого множества оценок.
4. Выборы открываются. Это тот момент, благодаря которому процесс получил свое имя "покер". Как и в игре в карты, вы показываете свою карту в тот момент, когда вас спрашивают.
5. Если все значения совпадают, то для этого элемента процесс останавливается, и его оценка считается установленной.
6. При различных оценках начинается дискуссия, когда каждый аргументирует свой выбор. Затем процесс повторяется, начиная с пункта 3, с учетом информации, полученной в ходе обсуждения.
7. Если процесс не сходится к общему значению, участники должны прервать дискуссию и обсудить, какую дополнительную информацию следует получить, отложив принятие решения на более поздний срок.

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

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

6.5 Внутренний потребитель

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

6.6 Открытое пространство

Методы agile уделяют внимание физической организации рабочего пространства.

Многие команды разработчиков традиционно используют, по крайней мере в США, личные офисы для ведущих сотрудников и кабинки для остальных. (В Европе кабинки менее распространены, более экстремальные форматы несовместимы с трудовым законодательством; в некоторых странах, например, требуется, чтобы каждый офисный работник имел доступ к дневному свету.)

Закрытые офисы и кабинки предаются анафеме в agile. Поскольку коммуникациям отводится главная роль, то, в соответствии с принципами, разработчики должны работать в открытом пространстве. Вот типичное высказывание на эту тему [Schwaber 2002]:

Используйте открытое рабочее пространство. Такое окружение позволит людям общаться более просто, что облегчает самоорганизацию. Когда я вхожу в открытую область, я могу непосредственно определить, как работается команде. Молчание всегда плохой признак. Слыша обсуждения, я понимаю, что люди сотрудничают. Когда я вхожу в помещение, разделенное на кабинки, то часто молчание указывает на отсутствие взаимодействия. Кабинки – это бич современного рабочего пространства. Они буквально разъединяют людей и разрушают команду.

Вот рекомендации agile:

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

Многим разработчикам, по моему опыту, нравится такое окружение, противоречащее стереотипу программиста как погруженного в себя зануды. Многие – не означает все; свидетельством является то, что многие ходят в наушниках, препятствующих шуму. Некоторые agile авторы говорят о необходимости хотя бы временного уединения – конуса тишины в терминах Кокбурна.

В самом деле, хотя основная идея звучит прекрасно и кабинки достойны всяческого презрения, хорошо, когда каждый может последовать примеру Кокбурна. Открытое пространство не является решением для всех людей и на все времена. Невозможно принять утверждение Швабера "Тишина – всегда плохой признак" как серьезное.

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

Нам всем знакомы примеры молчаливых программистов – интровертов, от которых на встречах не добьешься слова, но которые в одно прекрасное утро приходят с прекрасно спроектированной и реализованной подсистемой, которую все разговоры в мире не могли бы создать. Достойный труд рождает уважительное отношение к программистам (за которое решительно выступает Crystall). Следует принять, что люди различны и единая схема для всех не подходит. Уверен, можно молчаливого гения попросить пообщаться немного. Но если заставлять его участвовать во всех дискуссиях, то в результате он со своим талантом найдет более подходящее окружение.

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

Если "молчание – всегда плохой признак", то что можно сказать об обратной ситуации: рабочем пространстве, наполненном сплошным шумом? Это просто вызывает тревогу. Здоровое окружение, по моему опыту, то, в котором люди иногда говорят, а иногда молча читают, или пишут, или просто думают. Когда "входишь внутрь" рабочего пространства и видишь программиста, уставившегося в потолок, то только наивный (и, уверяю вас, некомпетентный) менеджер приходит к немедленному заключению, что программист зря тратит деньги компании.

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

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