Текст книги "Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство"

5. Реализация agile. Поставка в среде agile

Каждому проекту нужен устав проекта, чтобы команда проекта знала, для чего создается проект, в каком направлении нужно двигаться команде и в чем состоит цель проекта. Вместе с тем, одного устава проекта команде может быть недостаточно. Agile-командам требуются нормативы и понимание того, как вести совместную работу. В таком случае, команде может понадобиться устав команды.

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

Для проекта agile команде как минимум необходимо иметь общее представление о проекте или его цели, а также четкий набор рабочих соглашений. Устав проекта agile должен содержать ответы на следующие вопросы:

♦ Почему мы занимаемся этим проектом? Это общее видение проекта.

♦ Кто и как получит выгоды от проекта? Это может входить в общее видение проекта и/или в описание цели проекта.

♦ Что означает статус «сделано» для данного проекта? Это критерии релиза проекта.

♦ Как мы намерены работать совместно? Это объяснение предполагаемого потока работы.

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

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

♦ ценности команды, такие как равномерное распределение работы и обязательные рабочие часы;

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

♦ основные правила, такие как регламент выступления одного человека на совещании;

♦ групповые нормы, такие как отношение команды ко времени проведения совещаний.

Вместе с членами команды обслуживающий лидер может принять решение рассмотреть другие правила поведения.

Следует помнить, что «социальный договор» команды (т. е. ее устав) определяет порядок взаимодействия ее членов. Цель устава команды состоит в формировании среды agile, в которой члены команды могут вести работу в составе команды с полной отдачей как единое целое.

В разделах с 5.2.1 по 5.2.8 рассмотрены некоторые наиболее распространенные практики проектов agile.

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

Ретроспектива помогает команде учитывать опыт предыдущей работы над продуктом и своего процесса в прошлом. Один из принципов Agile-манифеста сформулирован следующим образом: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

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

♦ когда команда завершает релиз или поставляет что-либо – это не обязательно должен быть какой-то значительный инкремент, это может быть любой релиз, даже самый незначительный;

♦ по прошествии срока более нескольких недель после предшествующей ретроспективы;

♦ когда есть основания полагать, что в работе команды произошла заминка и поток завершенной работы в команде прекратился;

♦ когда в работе команды наступает какое-то контрольное событие.

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

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

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

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

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

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

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

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

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

♦ Уточнение «точно вовремя» для потокового agile. Команда берет для обсуждения следующую карточку из столбца, где указаны подготовленные рабочие задачи.

♦ Во многих командах, работающих в итерационном agile, проводятся обсуждения, ограниченные временными рамками продолжительностью 1 час, где-то посредине двухнедельной итерации. (Команда выбирает длительность итерации, которая обеспечивает им достаточную частоту обратной связи.)

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

ПОЛЕЗНЫЙ СОВЕТ

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

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

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

♦ предложить команде работать тройками с участием разработчика, тестировщика, бизнес-аналитика/владельца продукта при обсуждении и написании истории;

♦ представить команде полную концепцию истории – команда обсуждает и уточняет ее с разбивкой на несколько историй, если требуется;

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

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

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

Ограничьте временные рамки для летучки 15 минутами. Команда «проходит» доску «канбан» или доску рабочих задач тем или иным способом, и кто-либо из членов команды выступает фасилитатором на летучке.

В итерационном agile каждый из участников «по кругу» отвечает на следующие вопросы.

♦ Что я сделал(-а) после последней летучки?

♦ Что я планирую закончить в промежутке между этой и следующей летучкой?

♦ Какие у меня есть препятствия (или риски, проблемы)?

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

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

♦ Что нам требуется сделать, чтобы продвинуться вперед в исполнении этой части работы?

♦ Делает ли кто-нибудь какую-то работу, которая не указана на доске?

♦ Что нам нужно завершить как команде в целом?

♦ Существуют ли какие-то узкие места, мешающие потоку работы?

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

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

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

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

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

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

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

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

Команды дают оценку объема работы, который они смогут освоить, что является определенным показателем их ресурсной возможности (см. примеры в разделе 4.10). Команды не в состоянии с точностью до 100 % прогнозировать, что они будут в состоянии поставить, поскольку не могут учесть непредвиденные обстоятельства. Когда владельцы продукта готовят истории меньшего размера, а команды видят прогресс в форме конечного продукта, они узнают, что им по силам сделать при планировании на будущее.

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

ПОЛЕЗНЫЙ СОВЕТ

Следует привлечь внимание команды к неправильному подходу и помочь команде найти пути к улучшению ее летучек.

Если команда не уделяет внимания качеству, то вскоре она не сможет быстро выпускать что-либо.

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

♦ Непрерывная интеграция. Следует производить частую интеграцию работы в целое, независимо от продукта, и затем повторять тестирование, чтобы убедиться, что продукт в целом продолжает работать, как положено.

♦ Тестирование на всех уровнях. Следует проводить тестирование на уровне системы, чтобы получить информацию полного цикла, и испытания составных частей для создаваемых блоков. В промежутке следует изучить вопрос, есть ли необходимость производить интеграционные испытания и когда это лучше сделать. Команды находят полезным «дымовое» тестирование, чтобы убедится в пригодности рабочего продукта. Команды установили, что принятие решений о том, когда и какие именно проводить регрессивное тестирование, помогает им обеспечивать качество продукта при хорошем исполнении сборки. Agile-команды имеют сильную склонность к проведению тестирования в автоматическом режиме, чтобы наращивать и поддерживать темпы поставки.

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

♦ Разработка на основе тестов (TDD) и разработка на основе поведения (BDD). Написание программ автоматизированных тестирований до написания/создания продукта помогает людям в проектировании и проверке отсутствия в продукте ошибок. В не связанных с разработкой ПО проектах следует подумать, как направлять работу команды по проектированию на основе тестирования. В проектах по созданию аппаратных и технических средств для проведения промежуточных тестирований часто используются технологии симуляции.

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

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

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

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

ПОЛЕЗНЫЙ СОВЕТ

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

Таблица 5–1. Болевые точки подхода agile и возможности решения проблем

Таблица 5–1. Болевые точки подхода agile и возможности решения проблем (прод.)