Читать книгу Постигая Agile - Дженнифер Грин - Страница 16

Манифест гибкой разработки программного обеспечения, более известный как Agile-манифест, написан в 2001 году группой из 17 единомышленников, которые собрались на горнолыжном курорте Snowbird Retreat неподалеку от Солт-Лейк-Сити, чтобы придумать решение, способное помочь избежать проблем при разработке программного обеспечения, с которыми они сталкивались на протяжении всей своей карьеры. После нескольких дней обсуждения был принят основной набор идей и принципов (а также придумано название Agile). Собравшиеся объединили их в один документ, меняющий образ мышления в мире разработки программного обеспечения.

Agile-манифест содержит четыре простые идеи. Приведем полный текст.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь непосредственно разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

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

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

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

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

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Понимание и эффективная работа с Agile начинается с понимания этих ценностей.

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

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

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

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

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

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

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

Agile-команды ценят работающий программный продукт больше исчерпывающей документации. Но в данном случае важно понять смысл слова «работающий». Для agile-практика это такой продукт, который добавляет ценность организации. Например, программный продукт, на котором компания зарабатывает деньги, или ПО, обеспечивающее более эффективную деятельность сотрудников компании. Для проекта это означает, что он должен заработать или сэкономить больше денег, чем стоимость разработки программного продукта. Ценность всегда связана с деньгами, даже если никто не говорит об этом напрямую. И команда должна придавать особенное значение тому факту, что ценность ей придает сборка и поставка работающего ПО. Документация – лишь средство достижения этой цели.

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

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

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

Многие, читая «условия контракта», полагают, что они нужны лишь консультантам и подрядчикам, работающим в рамках контракта. На самом деле это касается многих команд, работающих в одной компании. Когда программисты, тестировщики, владельцы бизнеса и менеджеры проектов работают в разных командах и не сотрудничают в целях реализации единой рабочей программы, они часто ведут себя так, будто работают по разным контрактам. В большинстве компаний они явно будут обсуждать SLAs (service-level agreements – соглашения об уровне обслуживания) между командами программирования, тестерами и разработчиками, а также между командами и их пользователями.

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

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

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

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

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

Доска задач – хороший метод, помогающий команде правильно реагировать на изменения. Каждый элемент работы (как правило, пользовательская история) написан на карточке и прикреплен к доске – вроде той, которую Джоанна использовала для проекта «Музыкальный автомат». Все задачи обычно распределяют по трем столбцам, размещая их в том порядке, который показывает состояние каждой из них. Доска задач может управляться при помощи компьютерной программы. Но многие команды считают наиболее эффективным использование настенной доски, потому что, стоя перед ней, можно дискутировать и перемещать истории. Такая форма общения намного продуктивнее простого разговора. Доска создана так, что любой может изменить порядок задач, и даже рекомендуется это делать. Если происходят изменения, то любой может добавить учетные карточки на доску задач, а не удалять каждое изменение при помощи единого центра управления проектом. Это помогает держать всех в курсе дела, поэтому план не устаревает.