Agile-манифест помогает командам видеть цели применения каждой практики
Манифест гибкой разработки программного обеспечения, более известный как Agile-манифест, написан в 2001 году группой из 17 единомышленников, которые собрались на горнолыжном курорте Snowbird Retreat неподалеку от Солт-Лейк-Сити, чтобы придумать решение, способное помочь избежать проблем при разработке программного обеспечения, с которыми они сталкивались на протяжении всей своей карьеры. После нескольких дней обсуждения был принят основной набор идей и принципов (а также придумано название Agile). Собравшиеся объединили их в один документ, меняющий образ мышления в мире разработки программного обеспечения.
Agile-манифест содержит четыре простые идеи. Приведем полный текст.
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь непосредственно разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:Люди и взаимодействие важнее процессов и инструментов.Работающий программный продукт важнее исчерпывающей документации.Сотрудничество с заказчиком важнее согласования условий контракта.Готовность к изменениям важнее следования первоначальному плану.То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.Понимание и эффективная работа с Agile начинается с понимания этих ценностей.
Люди и взаимодействие важнее процессов и инструментов
Люди могут выбрать неправильный путь, если слепо следуют процессам. Отличный инструмент иногда помогает сделать неправильную вещь быстрее. Мир ПО полон отличных методов, но не все из них подходят для любого проекта или ситуации. Однако эта универсальность важна, чтобы лучше понимать, как члены команды работают вместе и как каждый человек влияет на всех остальных.
Это особенно полезно для тех, кто нуждается в улучшении работы команды. Вот почему agile-команды ценят людей и взаимодействие больше процессов и инструментов, которых явно недостаточно, чтобы иметь «правильные» процессы или «лучшие» методы. Если люди, которые должны использовать процесс или инструмент, не примут его, то он окажется отброшен в сторону. Еще хуже, когда члены команды следуют букве процесса, даже если это заканчивается неправильными результатами. Прежде чем реализовать даже самый логичный и осмысленный процесс, необходимо, чтобы люди, работающие с вами, приняли его. Если они не понимают смысла ваших действий, то будут считать, что вы просите о необоснованных изменениях.
Вот почему важно признать, что вы работаете с группой людей, каждый из которых имеет собственные мотивы, идеи и предпочтения.
Есть много agile-практик, которые поддерживают этот принцип, так же как и множество различных способов мышления. Поэтому в книге описаны ежедневные митинги и ретроспективы (где каждый рассказывает, как прошел день или итерация и какие уроки можно извлечь). И пользовательские истории важны в том числе и потому, что они помогают команде вести разговор о том, что означает каждая конкретная история.
Работающий программный продукт важнее исчерпывающей документации
Во всем мире существуют целые тома подробной и всеобъемлющей программной документации, стоящие на закрытых полках. Их так много, что трудно предсказать, какой документ пригодится, а какой будет бесконечно пылиться на полке. Из-за этого многие команды и особенно их руководители принимают комплексный подход, при котором каждая мелочь должна быть задокументирована независимо от того, понадобится ли это в будущем.
Agile-команды ценят работающий программный продукт больше исчерпывающей документации. Но в данном случае важно понять смысл слова «работающий». Для agile-практика это такой продукт, который добавляет ценность организации. Например, программный продукт, на котором компания зарабатывает деньги, или ПО, обеспечивающее более эффективную деятельность сотрудников компании. Для проекта это означает, что он должен заработать или сэкономить больше денег, чем стоимость разработки программного продукта. Ценность всегда связана с деньгами, даже если никто не говорит об этом напрямую. И команда должна придавать особенное значение тому факту, что ценность ей придает сборка и поставка работающего ПО. Документация – лишь средство достижения этой цели.
Приоритет работающего ПО над всеобъемлющей документацией не означает, что документы не нужны вовсе. Среди них очень много полезных для команды. Но важно иметь в виду, что документацию и программное обеспечение зачастую пишут одни и те же люди. Документация, помогающая им заранее, прежде чем они соберут ПО, понять проблему, общаться с пользователями и исправлять недостатки, экономит больше времени и усилий, чем нужно на ее создание. Часто также мы имеем дело с документацией такого рода, как каркасная визуализация или диаграммы последовательности, которые программисты вовсе не отказываются писать.
В то же время концентрация на работающем программном обеспечении – это отличный способ убедиться, что команда находится на верном пути. Работа над документацией, которая явно нацелена на создание работающего программного обеспечения, вносит позитивный вклад в проект. На самом деле часто команде может потребоваться новый подход к работе над документацией, что позволит этой документации быть встроенной в саму программу. Например, одна из agile-практик предлагает способ разработки ПО через тестирование: программисты строят автоматизированные модульные тесты до создания программного обеспечения, для проверки которого они предназначены. Эти тесты существуют в виде кода, хранящегося вместе с остальным кодом ПО. Но он также служит в качестве документации, потому что дает разработчикам сведения о том, что код должен делать и каким должно быть ожидаемое поведение отдельных элементов программного обеспечения.
Сотрудничество с заказчиком важнее согласования условий контракта
Многие, читая «условия контракта», полагают, что они нужны лишь консультантам и подрядчикам, работающим в рамках контракта. На самом деле это касается многих команд, работающих в одной компании. Когда программисты, тестировщики, владельцы бизнеса и менеджеры проектов работают в разных командах и не сотрудничают в целях реализации единой рабочей программы, они часто ведут себя так, будто работают по разным контрактам. В большинстве компаний они явно будут обсуждать SLAs (service-level agreements – соглашения об уровне обслуживания) между командами программирования, тестерами и разработчиками, а также между командами и их пользователями.
Это, конечно, снизит риск конфликтов с руководством (потому что в подобном случае легче обвинить другую команду за непоставку ПО), но не поможет достичь главной цели – получить работающее программное обеспечение, необходимое пользователям. Разработчик, занимающий круговую оборону, имеет меньше возможностей для поиска новых путей сотрудничества и инноваций с пользователями ПО.
Один из способов, который могут взять на вооружение agile-команды, – поставить владельца программного продукта в центр внимания, сделать его главным членом команды. Он может не заниматься активной разработкой кода, но будет присутствовать на планерках, вносить идеи и, главное, чувствовать свое право собственности на конечный продукт. Владельцы продукта часто воспринимают пользовательские истории как способ взаимодействия с остальными членами команды.
Готовность к изменениям важнее следования первоначальному плану
Существует старое правило управления проектами, которое гласит: «план работы – рабочий план». Если вы работаете по неправильному плану, то создадите неправильный продукт. Именно поэтому командам нужно постоянно следить за изменениями и быть уверенными, что они четко реагируют на них, если эти изменения нужны пользователям или процессу создания ПО. Когда ситуация меняется, проекту нужен новый план.
Сопротивление переменам – не редкость среди тех, кто создает план, потому что изменение плана требует дополнительных усилий. Возможно, было вложено много усилий в разбивку проекта на пакеты работ и оценку каждого этапа. Изменение в этом случае может потребовать от менеджера проекта переделки всей работы. И если для него следование первоначальному плану превыше готовности меняться, то ему придется и дальше проявлять упорство. Это делает работу над проектом более гладкой, но если изменения действительно необходимы, то это будет гораздо труднее сделать позднее, когда работа над кодом будет в самом разгаре.
Доска задач – хороший метод, помогающий команде правильно реагировать на изменения. Каждый элемент работы (как правило, пользовательская история) написан на карточке и прикреплен к доске – вроде той, которую Джоанна использовала для проекта «Музыкальный автомат». Все задачи обычно распределяют по трем столбцам, размещая их в том порядке, который показывает состояние каждой из них. Доска задач может управляться при помощи компьютерной программы. Но многие команды считают наиболее эффективным использование настенной доски, потому что, стоя перед ней, можно дискутировать и перемещать истории. Такая форма общения намного продуктивнее простого разговора. Доска создана так, что любой может изменить порядок задач, и даже рекомендуется это делать. Если происходят изменения, то любой может добавить учетные карточки на доску задач, а не удалять каждое изменение при помощи единого центра управления проектом. Это помогает держать всех в курсе дела, поэтому план не устаревает.
Рис. 2.3. Agile-команды часто используют доски задач, чтобы размещать на них задачи и отслеживать прогресс. Они будут писать задачи или пользовательские истории на карточках и перемещать их по доске, отмечая прогресс. Многие команды также рисуют диаграммы на своих досках, чтобы демонстрировать прогресс
Принципы превыше методов
Наша команда музыкального автомата получила хорошие результаты, потому что воспользовалась некоторыми прекрасными методами и благодаря им смогла улучшить проект. Но из-за раздробленного видения члены команды не получили полной отдачи от совместной работы над усовершенствованием способа создания ПО. Существует agile-мышление, которое выходит за рамки практик, и команды, ищущие свой путь к ключевым идеям Agile, найдут лучший способ сотрудничества и взаимодействия.
Другими словами, команда, использующая agile-практики, чтобы построить рабочее программное обеспечение, и находящая ценность работы с клиентами во взаимодействии и сотрудничестве с ними, в ответ на собственные изменения получит больше от своих проектов, чем те, кто просто применяет лучшие методы планирования, программирования и ведения документации.
Джим Хайсмит удачно обобщил эту идею в своей книге Agile Project Management: Creating Innovative Projects:
Без конкретных практик принципы бесплодны, но без принципов в практиках нет жизни, нет характера, нет сердца. Великие продукты возникают у великих команд – принципиальных, которые имеют характер, у кого есть сердце, упорство и мужество.
Так как команды выходят за рамки простого принятия методов и становятся «принципиальными», могут ли они создавать отличные продукты?
Ключевые моменты
Agile-манифест содержит общие ценности и идеи, которые делают команды эффективными.«Люди и взаимодействие важнее процессов и инструментов» означает, что команда должна сосредоточиться на людях и прежде всего на том, как они общаются, а затем уже на инструментах и методах, которые они используют.«Работающий программный продукт важнее исчерпывающей документации» означает, что поставка программного обеспечения, которое делает именно то, что от него нужно пользователю, значительно ценнее, чем поставка спецификации, описывающей это ПО.«Работающий программный продукт» означает такое ПО, которое обеспечивает ценность компании.«Сотрудничество с заказчиком важнее согласования условий контракта» означает уважительное отношение ко всем, как будто они в одной команде.Многие эффективные agile-команды рассматривают владельца продукта в качестве члена проектной группы, с которым нужно сотрудничать, а не только вести переговоры как с клиентом или заказчиком.«Готовность к изменениям важнее следования первоначальному плану» означает признание того, что планы становятся неточными, и поэтому главное – поставить программное обеспечение, а не только разработать план работы.Доска задач – это инструмент agile-планирования, в котором пользовательские истории крепятся к доске и делятся на столбцы в зависимости от своего статуса в текущем проекте или итерации.
Назад: Раздробленное видение
Дальше: Понимание слона
