Чего мы хотим от вас. Разумеется, самое лучшее – это просто начать делать! Но не всем это по душе, а один из главных постулатов книги состоит в том, что попытки внедрять практику в условиях, когда мировоззрение компании не совпадает с ней, могут окончиться плохо. Так что прежде всего подумайте, как отреагирует команда. Это может быть не менее эффективным инструментом обучения, чем само выполнение задания.
Обозначаются значком . Исаак Ньютон однажды сказал: «Если я видел дальше других, то потому, что стоял на плечах гигантов». Нам повезло: сейчас существует множество революционных книг по гибкой разработке ПО. После каждой главы мы предлагаем список из нескольких источников, в которых можно найти больше сведений по конкретной теме.
Чего мы хотим от вас. Продолжайте учиться! Наша книга подробно рассказывает о Scrum, XP, Lean и Канбан, но, конечно, мы не можем исследовать все эти идеи детально. Большинство идей, описанных здесь, придумано не нами. К счастью, вы можете учиться и у тех, кому они принадлежат.
Обозначаются значком . Agile-коуч – это человек, который помогает командам овладеть Agile. Книга написана для тех, кто только обучается Agile, но ее могут использовать и опытные agile-коучи, внедряющие эти идеи в свою команду. Ищите советы для тренеров в конце каждой главы. Они помогут применить идеи и подход, которые используем мы, и адаптировать их к вашей команде.
Чего мы хотим от вас. Даже если вы не коуч, все равно стоит прочитать советы для тренеров. Дело в том, что один из самых эффективных методов обучения – попробовать себя в роли наставника. Если вы узнаете об этих идеях впервые, то подумайте, как можно использовать советы для тренеров, чтобы помочь команде больше узнать об Agile.
Структура книги
Эта книга устроена так, чтобы помочь вам понять agile-методологии, усвоив ценности и принципы эффективной команды разработки, школ, которые воплощают эти ценности, и методик, при помощи которых они реализуются.
Две следующие главы помогут понять ценности и принципы, которые будут способствовать переходу на гибкое мировоззрение. В них приведены способы, благодаря которым можно оценить, готовы ли вы и ваша команда принять agile-методологии, какие именно ее части найдут отклик у коллег и что может оказаться наиболее сложным для внедрения.
• Глава 2 описывает ключевые ценности Agile. Мы расскажем о команде, бьющейся над программным проектом, и объясним, что основной источник затруднений – это «искаженная перспектива». Мы изложим ценности Agile и при помощи метафоры поможем увидеть, как они дают возможность команде увидеть общую перспективу.
• Глава 3 рассказывает о принципах, в соответствии с которыми agile-команды принимают решения о том, как управлять проектами. Мы поясним, какие цели и идеи лежат в основе этих принципов, проиллюстрировав их практическим примером из программного проекта.
В следующих шести главах говорится о самых популярных школах Agile: Scrum, XP, Lean и Канбан. Вы узнаете, как их применять и внедрить в практику работы вашей команды.
• Глава 4 описывает Scrum, популярный agile-подход, чтобы рассказать о том, как работают самоорганизующиеся команды. Мы дадим несколько советов, как применить технологию Scrum к вашим проектам и обучить команду самоорганизации.
• Глава 5 демонстрирует конкретные процедуры, которые используются в scrum-командах для управления проектами, и объясняет, как эти процедуры помогают команде объединиться и создать качественные программы. Мы покажем, что успех реального перехода на Scrum зависит от того, насколько полно ценности Scrum соответствуют культуре вашей команды и компании, и поясним, что делать, если различия слишком сильны.
• Глава 6 рассказывает об основных методах экстремального программирования, его ценностях и принципах. Вы узнаете, как каждому члену команды прививается мировоззрение, необходимое для улучшения работы над кодом: вместо того чтобы ненавидеть перемены, все сотрудники учатся принимать их с готовностью.
• Глава 7 рассказывает о трех основных методах экстремального программирования и о том, как они помогают избежать серьезных проблем с кодом и проектированием. Вы поймете, что все методы экстремального программирования образуют единую экосистему, которая ведет к созданию лучшего кода – более гибкого, изменяемого и простого в обслуживании.
• Глава 8 знакомит с бережливым программированием и принципами, которые помогут обрести соответствующее мировоззрение. И мы покажем, что методы размышлений, предлагаемые бережливым программированием, могут помочь вашей команде найти излишне предпринимаемые действия и избавиться от них, а также увидеть общую картину системы, в рамках которой вы разрабатываете ПО.
Рис. 1.4. Графическая запись выступления Эндрю Стеллмана на конференции Stretch 2013 в Будапеште (Венгрия). Выступление было основано на материалах этой главы
Графическая запись: Ката Мате и Марти Фридик, www.remarker.eu
• Глава 9 рассказывает о Канбане, его принципах и взаимоотношениях с бережливым программированием, а также о методах. Вы узнаете, как концентрация на потоке и теории массового обслуживания поможет вашей команде претворить в жизнь идеалы бережливого программирования. Также вы поймете, как Канбан может создать в команде культуру постоянного совершенствования.
В мире 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-проект, до тех пор, пока она не поймет, как эти ценности действительно применимы к ней. Читая эту историю, обратите внимание на то, как лучшее понимание ценностей помогает избежать проблем.