AGILE-ПОДХОД К ПРОЕКТУ
«Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. На помощь приходит agile-подход. Благодаря agile вы научитесь создавать реалистичные планы, которые сможете корректировать по ходу работы, при этом выполняя проекты в срок и в рамках бюджета. […]
Почему agile-подход к оценке и планированию более эффективен, чем традиционные методы? Он сконцентрирован на создании стоимости и формировании доверительных отношений между заказчиком и проектными командами. Обеспечение полной прозрачности и информирование об изменениях по мере их появления позволяют заказчику принимать наилучшие решения.
Основные аспектам работы agile-команд:
«- работа единой командой;
Критически важно для успеха проекта, чтобы все участники считали себя членами одной команды, имеющей общую цель. В agile-проекте нет места менталитету «самоустранение от участия в дальнейшем процессе после выполнения своей непосредственной задачи».
Хотя agile-команда должна работать как единое целое, в ней есть целый ряд конкретных ролей.
Первая роль — владелец продукта. В число основных обязанностей владельца продукта входит формирование общего видения проекта у всех членов команды, определение приоритетов, обеспечивающих разработку наиболее ценной функциональности в первую очередь, а также принятие решений, направленных на получение хорошей рентабельности инвестиций в проект. […]
Вторая роль — клиент. Клиент — это лицо, которое принимает решение о финансировании проекта или о покупке программы. В проекте по разработке программного обеспечения для внутреннего пользования клиент обычно является представителем другой группы или подразделения. В таких проектах роли владельца продукта и клиента нередко совмещаются. В случае продукта, распространяемого на коммерческой основе, в роли клиента выступает лицо, которое покупает программу. В обеих ситуациях клиент может с равным успехом быть пользователем программного обеспечения или не быть им, и это самостоятельная важная роль.
Еще одна роль, которую следует отметить, — разработчик. Я использую понятие «разработчик» в очень широком смысле, подразумевая любого разработчика программного обеспечения. В их число входят программисты, тестировщики, аналитики, администраторы баз данных, юзабилити-эксперты, технические писатели, системные архитекторы, дизайнеры и т.д. При таком подходе к использованию данного термина даже владелец продукта может считаться разработчиком ряда проектов.
Последняя роль — руководитель проекта. Как пишет Хайсмит (Highsmith, 2004a), роль руководителя проекта изменяется в случае применения agile-подхода. Руководители agile-проектов концентрируют внимание больше на лидерстве, а не на менеджменте. В некоторых agile-проектах лицо, выполняющее роль руководителя проекта, выступает также и в другой роли: нередко как разработчик, а иногда как владелец продукта.
- работа короткими итерациями;
… как только начинается реальное осуществление проекта, все работы (анализ, дизайн, программирование, тестирование и т.п.) выполняются параллельно на каждой итерации. Итерации ограничиваются по времени, т.е. они завершаются вовремя, даже если приходится урезать функциональность. Большинство команд выбирают сравнительно постоянную длину итераций, вместе с тем существует также практика определения подходящей длины перед началом каждой итерации.
- поставка какого-либо результата после каждой итерации;
Более важным, чем выбор определенной длины итерации, является то, что в процессе итерации команда превращает одно или несколько неточно сформулированных требований в скомпонованную, протестированную и потенциально готовую к поставке программу. Конечно, многие команды не поставляют результаты каждой итерации пользователям — цель заключается в том, чтобы это в принципе можно было сделать. Это означает, что команда последовательно добавляет одну или несколько небольших функций во время каждой итерации, но каждая добавленная функция встроена в продукт, протестирована и имеет качество, необходимое для релиза.
Принципиально важно, чтобы к концу каждой итерации продукт находился в потенциально готовом к поставке состоянии. На практике это не означает, что команда должна сделать абсолютно все необходимое для выпуска продукта, — в конце концов, релизы необязательно выпускаются после каждой итерации. Например, я работаю с командой, которой нужно два месяца на тестирование среднего времени наработки на отказ, включающее и аппаратную часть, и программное обеспечение. Она не может сократить этот срок, поскольку он оговорен клиентом в контракте и именно такое время зачастую необходимо для выявления сбоев аппаратной части. Команда работает с четырех недельными итерациями, и, помимо тестирования среднего времени наработки на отказ, она доводит свой продукт до работоспособного состояния в конце каждой итерации.
Поскольку одной итерации обычно недостаточно по времени для включения новой функциональности, удовлетворяющей потребности пользователя или клиента, вводится более широкая концепция релиза. Релиз содержит одну или несколько (обычно несколько) итераций, которые последовательно дополняют друг друга, давая полный набор соответствующих функций. Если итерации чаще всего длятся от двух до четырех недель, то на релиз обычно требуется от двух до шести месяцев. Например, в системе управления инвестициями один релиз может включать все функции, связанные с покупкой и продажей взаимных фондов и фондов денежного рынка. На завершение такого релиза могут потребоваться шесть двухнедельных итераций (примерно три месяца). Второй релиз может добавить торговлю акциями и облигациями и потребовать четыре дополнительные двухнедельные итерации. Релизы могут выпускаться с разными интервалами. Скажем, на разработку первого релиза необходимо шесть месяцев, следующего релиза — три месяца и т.д.
- фокус на бизнес-приоритетах;
Agile-команды демонстрируют приверженность бизнес-приоритетам двумя путями. Во-первых, они поставляют функции в порядке, определенном владельцем продукта, который должен ранжировать и объединять функции в релиз таким образом, чтобы оптимизировать рентабельность инвестиций организации в проект. С этой целью составляется план релиза на основе возможностей команды и ранжированного по приоритетности перечня желаемых новых функций. Для обеспечения владельцу продукта максимальной гибкости приоритизации функции необходимо описать так, чтобы минимизировать их техническую взаимозависимость. Владельцу продукта сложно ранжировать функции по приоритетности в плане релиза, если выбор одной функции требует предварительной разработки трех других. Команде вряд ли удастся полностью исключить взаимозависимости, однако во многих случаях достаточно свести их к минимуму.
Во-вторых, agile-команды фокусируются на разработке и поставке ценных для пользователей функций, а не на выполнении изолированных задач (которые в конечном итоге объединяются в ценную для пользователей функцию). Одним из лучших подходов к этому является работа с пользовательскими историями, которая представляет собой облегченную методологию представления требований к программному обеспечению (Cohn, 2004). Пользовательская история — это краткое описание функциональности с точки зрения пользователя или клиента системы. Пользовательские истории излагаются в свободной форме, какие-либо синтаксические правила их составления отсутствуют. Тем не менее в целом неплохо придерживаться следующей формы: «Как <тип пользователя> я хочу <иметь возможность> с тем, чтобы <деловая ценность>». Воспользовавшись этим шаблоном, можно написать, например, такую историю: «Как покупатель книг я хочу осуществлять их поиск по номеру ISBN с тем, чтобы быстро отыскивать нужное издание».
Пользовательские истории являются облегченной методологией, потому что работа по их сбору и документированию не выполняется заранее. Вместо составления объемных спецификаций с описанием требований agile-команды предпочитают использовать подход «точно вовремя». Обычно он начинается с короткого описания пользовательской истории на карточке или, возможно, в компьютере (в случае большой и распределенной команды). Впрочем, карточка с историей — это всего лишь отправная точка, и каждая пользовательская история сопровождается диалогами между разработчиками и владельцем продукта. Такие диалоги происходят по мере необходимости, и в них участвуют все, кому это требуется. Использование подхода на основе пользовательских историй не мешает существованию обычной письменной документации. Вместе с тем фокус кардинальным образом смещается с письменного общения в сторону устного.
- проверка и модифицирование.
План, принятый в начале проекта, не является гарантией того, что произойдет далее. По существу, это всего лишь существующее в данный момент предположение о том, что произойдет. Против плана работает множество событий — исполнители могут присоединяться к проекту или уходить из него, технологии могут работать лучше или хуже ожидаемого, пользователи могут менять свое мнение, конкуренты могут заставить нас реагировать иным образом или действовать быстрее и т.д. Agile-команды воспринимают любое такое изменение как возможность и необходимость обновления плана, с тем чтобы он лучше отражал реалии текущей ситуации.
В начале каждой итерации agile-команда учитывает все новые знания, полученные на предыдущей итерации, и соответствующим образом модифицирует проект.
Ценность плана может измениться в результате получения владельцем продукта определенных знаний о потребностях вероятных пользователей. Возможно, из отзывов пользователей о программе, полученной в предыдущей итерации, владелец
продукта узнает, что одну функцию они хотели бы расширить, а другая функция не заинтересовала их в той мере, в какой предполагалось».
Agile: оценка и планирование проектов / Майк Кон»: Альпина Паблишер; Москва; 2018, с.27-29
