Постигая Agile

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

Иллюстрации

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

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

Избыточность

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

Чего мы хотим от вас. Когда вы читаете об одном и том же по несколько раз, возникает искушение спросить: «Разве об этом уже не говорили?» Говорили! И очень хорошо, что вы это заметили. Но есть читатели, которые не обратили на это внимания, да и вы сами наверняка не каждый раз замечаете избыточность. Все это делается для того, чтобы помочь вам учиться.

Упрощение (в первую очередь!)

Иногда сложную тему проще понять, если сначала едва коснуться ее и лишь затем погрузиться полностью. В книге мы так и поступаем: сначала вводим упрощенную (но технически верную!) версию идеи, а затем конкретизируем ее. Этот метод работает на двух уровнях. Если вы глубоко понимаете данную идею, то сразу заметите упрощение и эмоционально на него отреагируете, что сохранит вашу заинтересованность. Но если вы незнакомы с идеей, упрощение послужит легким толчком, который подготовит вас к более глубокому описанию.

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

Разговорный (привычный) стиль

На протяжении всей книги мы пользуемся разговорным языком, чтобы сделать излагаемый материал максимально привлекательным. Мы не забываем о юморе и время от времени – ссылках на литературные источники, а порой обращаемся непосредственно к вам или к себе, используя личные местоимения. На самом деле это научно обоснованно: когнитивные исследования[5] показали, что мозг запоминает больше информации, если во время разговора вы испытываете чувства.

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

Ключевые моменты

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

Чего мы хотим от вас. Не закрывайте разделы «Ключевые моменты» сразу. Уделите им хотя бы минутку. Вы помните все, что в них описано? Если нет, то не поленитесь вернуться на несколько страниц назад, чтобы освежить память.

Часто задаваемые вопросы

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

Чего мы хотим от вас. Прочтите в конце каждой главы раздел «Часто задаваемые вопросы». Есть ли среди них тот, который волнует именно вас? Если да, то удовлетворяет ли вас ответ? Не все ответы подходят к вашему случаю, но постарайтесь и в них найти рациональное зерно. Если все вопросы в разделе неактуальны для вас, то подумайте, с какой целью их могли задать. Так можно по-новому взглянуть на материал (в главе 2 вы узнаете, почему это важно для команды).

Что вы можете сделать уже сегодня

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

Чего мы хотим от вас. Разумеется, самое лучшее – это просто начать делать! Но не всем это по душе, а один из главных постулатов книги состоит в том, что попытки внедрять практику в условиях, когда мировоззрение компании не совпадает с ней, могут окончиться плохо. Так что прежде всего подумайте, как отреагирует команда. Это может быть не менее эффективным инструментом обучения, чем само выполнение задания.

Где вы можете узнать больше

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

Чего мы хотим от вас. Продолжайте учиться! Наша книга подробно рассказывает о 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

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

Аристотель. Никомахова этика[6]

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 часов в неделю, если код давал сбои. Джоанна объяснила, что главная причина этих неудач – неспособность водопадного подхода, принятого в компании, справляться с изменениями. В идеальном мире водопадный подход работал бы прекрасно, потому что на старте проекта известно, что нужно получить в конце. Таким образом, можно было бы записать все в виде аккуратной спецификации и передать команде разработчиков. Но в реальных проектах так не бывает.

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

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

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

Серебряной пули не существует

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

(По иронии судьбы одна из самых цитируемых работ в области программной инженерии – это эссе Фреда Брукса No Silver Bullet («Серебряной пули не существует», 1986). В нем он убедительно доказывает, что эта задача невыполнима. Что еще нужно, чтобы остановить бесплодные попытки найти загадочную панацею?)

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

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

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

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

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

Но для запуска успешного водопадного проекта требуется нечто большее, чем просто стандартные требования, отсутствие которых создает так много проблем. Команды, разрабатывающие прекрасное ПО при помощи водопадного подхода, как правило, имеют несколько общих характеристик. Это:

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

• хорошие методики, особенно такие как анализ кода и автоматизированное тестирование, которые направлены на поиск ошибок на раннем этапе. Обычно это называется «предотвращение дефектов» и необходимо команде, чтобы прежде всего понять, как эти ошибки попали в код;

• ящики, полные документации, которые редко открываются, потому что люди в команде понимают, что сам факт написания плана и вопросы, которые возникают во время планирования, – это важнее, чем слепое следование этому плану.