Постигая Agile - Дженнифер Грин

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

• Глава 10 рассказывает о работе agile-коучей: как учатся команды, как коуч помогает изменить мировоззрение, чтобы легче было взять на вооружение agile-методологии и стать более гибкими.

Глава 2. Понимание ценностей Agile

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

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

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

Благодаря Agile наша отрасль оказалась на переломе своего развития. Agile из аутсайдера превратился в работающий институт. В течение первых лет существования этого метода принявшие его люди активно старались убедить свои компании и коллег, что Agile действительно приносит пользу и им стоит заниматься. В настоящее время практически не осталось сомнений, что agile-методологии – это эффективный способ создания программного обеспечения. В 2008 году было проведено исследование[7], которое показало, что более половины всех опрошенных команд, занимающихся разработкой программных продуктов, используют agile-методологии, практики или принципы. С тех пор актуальность Agile только выросла. Agile-команды все чаще задумываются не только над тем, как стать более гибкими, но и как распространить Agile в своих компаниях.

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

История Agile началась, когда небольшая группа новаторов задумалась о новых способах решения этих проблем. Первым делом они составили список из четырех основных ценностей, общих для успешных команд и проектов (этот документ получил название Manifesto for Agile Software Development, или «Манифест гибкой разработки программного обеспечения»).

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий программный продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

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

Дэн – ведущий разработчик и архитектор

Брюс – лидер команды

Джоанна – недавно нанятый менеджер проекта

Том – владелец продукта

Руководитель команды, архитектор и менеджер проекта заходят в бар…

Дэн – ведущий разработчик и архитектор в компании, которая создает игровые автоматы и киоски. Он участвовал в различных проектах, от аркадных игр и пинбола до ПО для банкоматов. Последние несколько лет он работал в команде, возглавляемой Брюсом. Команда занималась выпуском крупнейшего продукта компании, слот-машины Slot-o-matic Weekend Warrior («Боец по выходным»).

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

Дэна и Брюса новый проект вдохновляет меньше, чем Джоанну. Как-то раз они зашли выпить после работы, и Брюс с Дэном начали объяснять Джоанне, почему команда придумала для слот-машины имя «Боец по выходным».

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

Слушая их рассказ, Джоанна поняла, что стало причиной проблем: компания использовала самую неэффективную методику – водопадный подход. В рамках этой модели требуется как можно раньше создать полное описание программного обеспечения, которое будет разрабатываться. После того как все пользователи, менеджеры и руководители согласуют точные требования к программному продукту, они могут подписать документ (спецификацию). Он содержит требования к команде разработчиков, которая создает именно то, что написано. После этого приходят тестировщики и проверяют, соответствует ли программное обеспечение документу. Многие agile-практики называют это «большими требованиями вначале» (big requirements up front, или BRUF).

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

Рис. 2.1. Модель водопадного подхода

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

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

Обе эти проблемы привели к массе неудавшихся проектов, особенно с учетом тех случаев, когда им приходилось работать по 90 часов в неделю, если код давал сбои. Джоанна объяснила, что главная причина этих неудач – неспособность водопадного подхода, принятого в компании, справляться с изменениями. В идеальном мире водопадный подход работал бы прекрасно, потому что на старте проекта известно, что нужно получить в конце. Таким образом, можно было бы записать все в виде аккуратной спецификации и передать команде разработчиков. Но в реальных проектах так не бывает.