Эндрю Стеллман, Дженнифер Грин, «Постигая Agile. Ценности, принципы, методологии». – М.: «Манн, Иванов и Фербер», 2017.
Эта книга рассказывает о самых популярных agile-подходах — Scrum, XP (экстремальное программирование), Lean (бережливое программирование) и Канбан. Она познакомит вас с методами, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут вашей команде полностью изменить свой подход к работе над проектами. Вы начнете лучше разбираться в конкретных agile-подходах и сможете сразу внедрить их на практике. А главное, вы поймете, как превратить группу сотрудников, добавляющих в свою работу Agile, в настоящую команду, которая действительно улучшает способ создания продукта и добивается выдающихся результатов.
Вы когда-нибудь замечали, как часто программисты жалуются на своих пользователей? Немного побродив по специализированным программистским форумам, вы наверняка наткнетесь на ветку, где разработчики сетуют, что пользователи сами не знают, чего хотят, когда просят написать для них программу. Это стало частью культуры программистов: клиенты никогда не говорят, чего они хотят на самом деле, и осложняют жизнь программиста, то и дело меняя свои требования.
Выше уже говорилось, как Scrum предлагает решать эту проблему: непосредственные контакты с пользователями позволяют понять, что для них ценно, а частая поставка работающего ПО дает представление о том, как меняются потребности. Это дает руководителям проекта и владельцам бизнеса возможность постоянно пересматривать цели проекта, раз это обеспечивает максимальную отдачу. Значит, чтобы поспевать за изменением требований пользователей, команда должна постоянно корректировать код. Но разработчики знают, что внесение изменений в код приводит к ошибкам. Чем больше их вносится, тем более хрупким получается код. Любые ли правки кода приводят к ошибкам и нестабильности?
Это одна из тех проблем, с которыми справляется гибкая методология XP (Extreme Programming – экстремальное программирование). Как и Scrum, она состоит из практик, ценностей и принципов. Практики просты в освоении и весьма эффективны – они могут изменить ваш подход к работе. Но, как и в Scrum, эти изменения происходят, если члены команды воспринимают их правильно.
В этой главе вы узнаете об основных практиках XP и о том, как они могут быть применены командой программистов (или, наоборот, использованы неверно). Вы узнаете о ценностях и принципах ХР и о том, как они способствуют формированию правильного мировоззрения у каждого члена команды, помогающего создавать более качественный код. Вместо того чтобы ненавидеть изменения, каждый человек в команде учится их принимать.
Описание: команда занимается разработкой баскетбольного сайта
- Джастин – первый разработчик
- Даниэль – второй разработчик
- Бриджит – менеджер проекта
Акт I. Сверхурочная работа
Джастина всегда охватывало странное чувство, когда он задерживался в офисе допоздна. Ему казалось, что он выпил слишком много кофе, хотя на самом деле это было не так. Но он никогда не испытывал ничего подобного, работая по ночам дома.
– Похоже, предстоит одна из таких ночей, – сказала Даниэль, напарница Джастина. Они подружились в колледже. Она училась на два курса старше на том же самом факультете информатики – одном из лучших в стране. Кроме того, они были напарниками на занятиях в химической лаборатории. Даниэль дала ему рекомендацию, когда он устраивался разработчиком онлайновой фантазийной баскетбольной игры в Chalk Player Online. Эта компания занимается разработкой сайтов на спортивную тематику, и она оказалась его первым работодателем.
Джастин никогда не имел намерений задерживаться в офисе. Не то чтобы у него были проблемы с работой по ночам. Руководитель проекта Бриджит тоже ничего не имела против того, чтобы он трудился допоздна, особенно если он делал это из дома. Но как-то вечером Джастин обнаружил, что уже 10 вечера, а он все еще сидит на рабочем месте и отправляет письмо с извинениями подружке, а соседу по комнате – просьбу выгулять собаку.
Забавно, что незадолго до этого они с Даниэль обсуждали, что неплохо было бы уйти сегодня домой вовремя. Но в конце дня Бриджит сообщила плохие новости: состоялась встреча с менеджерами продукта и появилась необходимость внести в код большое количество изменений. При запуске проекта предполагалось, что он будет включать только команды NBA. Но теперь менеджеры продукта решили, что добавление европейских баскетбольных команд принесет намного больше денег.
И вот Джастин и Даниэль снова задерживаются на работе.
– Это действительно нечестно, – сказал Джастин. – Мы твердо согласовали с ними более трех месяцев назад, что будем использовать только команды NBA.
– Мог бы и не напоминать мне об этом. Та встреча была моей идеей, – добавила Даниэль.
– И после всего этого они хотят, чтобы мы добавили эти команды. Нам придется выдрать много кода и сделать довольно серьезные изменения в базе данных. – Он замолчал на секунду. – Знаешь, я виню Бриджит. Я так зол на нее. Она просто не понимает, как это будет тяжело.
Даниэль испуганно смотрела куда-то мимо Джастина.
– Бриджит стоит у меня за спиной?
– Да, – сказала Бриджит. – Послушай, я прекрасно понимаю, насколько это серьезные изменения.
– Но это не просто изменения, – ответил Джастин. – Мы объяснили им, что именно собираемся сделать. Это было несколько месяцев назад. Они подписались под этим. Если бы они предупредили о европейских лигах тогда, то мы бы разработали нечто совершенно другое. Система, которую мы программируем, не дает возможности использовать несколько лиг, поскольку речь шла только об одной.
– Таким было исходное предположение, – добавила Даниэль, – и его изменение полностью меняет подход к проектированию системы. Мы собираемся выдирать большие куски кода, а это приведет к появлению проблем.
– Каких проблем? – спросила Бриджит.
– Вы когда-нибудь чинили автомобиль при помощи скотча и скрепок? – поинтересовался Джастин. – Так вот, это похожий случай.
Все переглянулись и поняли: впереди много бессонных ночей.
Основные практики ХР
Существует 13 основных практик экстремального программирования, которые могут помочь команде найти входы и выходы в разработке программного обеспечения и создавать легко изменяемый код. В отличие от scrum-практик, многие ХР-практики имеют особенности и направлены на решение самых распространенных проблем, провоцирующих создание плохого кода. В этих практиках все настолько тесно связано с программированием, что многие люди ошибочно считают: XP – это только для высококвалифицированных специалистов.
В этой главе мы поговорим о 10 основных практиках XP. Эти 10 практик разделены на четыре категории – программирование, интеграция, планирование и команда, – чтобы их легче было понять и удержать вас от заблуждения, будто методика XP пригодна только для суперразработчиков.
1. Практики программирования
Две основные практики XP – разработка через тестирование и парное программирование – предназначены специально для программистов и помогают им писать более качественный код. Они сосредоточены на нескольких важных аспектах разработки программного обеспечения. Созданием автоматизированных тестов перед написанием кода и его последующим тестированием команды повышают качество программного обеспечения. Работая вдвоем на одном компьютере, разработчики более тщательно вычитывают код в поиске ошибок.
Когда программист делает разработку через тестирование, которую обозначают аббревиатурой TDD (test-driven development), он создает автоматизированный тест перед тем, как начнет писать код. И пока код продукта не написан, тест будет завершаться провалом. Программист понимает, что код работает, когда тест оказывается пройден. Это создает петлю жесткой обратной связи, помогающую предотвратить появление дефектов: сначала написание проверочных тестов, затем создание кода, способного их пройти, поиск проблем и путей их решения и написание дополнительных проверочных тестов. Такие автоматизированные тесты обычно называют модульными. Слово «модуль» используется неслучайно: почти во всех языках программирования код очевидным образом разделяется на модули (классы, методы, функции, подпрограммы...), и практически любой язык предоставляет как минимум один способ создания и запуска автоматических тестов, которые привязаны к каждому из этих модулей. Создав вначале тесты, программист гарантирует, что все написанные им модули будут работать корректно.
Разработка через тестирование позволяет убедиться лишь в том, что каждый отдельно взятый модуль работает. Это также помогает командам предотвратить некоторые из самых распространенных и серьезных проблем, которые могут создать трудности в ходе поддержки кода. Можно внести изменения в одну часть кода и обнаружить, что неожиданно появились ошибки в другой части, которая, казалось бы, никак не связана с первой. И это только потому, что разработчик не подозревал о существовании зависимости между ними. Когда программист пишет модульные тесты, использующиеся каждый раз при сборке кода, эти автоматизированные тесты помогают избежать появления зависимостей, которые, оставшись невыявленными, приведут к немедленному сбою. Тесты помогают программисту заметить проблему, прежде чем она окажется встроенной в общий код и ее будет трудно удалить. Кроме того, модульные тесты помогают разработчикам писать код, который легче использовать повторно. Например, программист может создать класс Java, работа с которым чрезмерно усложнена: использовать в нем сбивающие с толку имена, неудобную инициализацию или другие структурные проблемы, которые смогут легко пробраться в код любого разработчика. Когда программист создает модульный тест, использующий такой класс, изъян может стать очевидным и, так как код класса еще не написан, разработчику несложно устранить этот изъян.
Затем модульный тест становится частью исходного кода, так что другие программисты могут опираться на него, чтобы увидеть, как этот метод предполагалось использовать.
Вторая основная ХР-практика, ориентированная на написание кода, – парное программирование. В команде, занимающейся парным программированием, два разработчика пишут код, сидя за одним компьютером. В большинстве случаев один программист сидит за клавиатурой, а другой наблюдает, и они постоянно обсуждают, что делают. Команды, работающие в парах, вносят гораздо меньше ошибок, потому что за процессом внимательно следят две пары глаз. Парная работа также помогает уменьшить усталость, потому что один программист может печатать, когда другой устал. Эффективные команды парного программирования обсуждают идеи и подходы, постоянно устраивают мозговые штурмы и поэтому более инновационны. Они также несут ответственность друг перед другом за правильное применение практики: одному проще словчить, а под наблюдением партнера сделать это гораздо сложнее. Многие разработчики рассказывали нам, что программисты в парах пишут код быстрее и лучшего качества, чем работая по отдельности.
2. Практики интеграции
Существуют две основные XP-практики, которые мы относим к категории «интеграция». Первая – это десятиминутная сборка. Команда создает автоматизированную сборку для всей кодовой базы, которая длится 10 минут. Эта сборка включает в себя автоматический запуск всех модульных тестов и генерацию отчетов с положительными и отрицательными результатами.
«Десять минут» может звучать как произвольная величина, но с точки зрения команды она имеет смысл. Если сборка проекта занимает более 10 минут, то члены команды запускают ее гораздо реже. Но для команды очень важно использовать ее часто, потому что это быстро выявляет проблемы. Например, в сборке запускаются модульные тесты, поэтому после ее завершения команда знает, достигла ли она нужного качества.
Иными словами, она позволяет быстро получить ответ на вопрос «Работает ли еще наш код?». И благодаря тому, что сборка довольно короткая, команда будет запускать ее часто, а каждый член команды получит постоянно обновляемую картину качества кода.
Другая интеграционная практика – это непрерывная интеграция. Она реализуется благодаря набору инструментов, позволяющих нескольким членам команды одновременно работать с одной версией исходного кода. Если несколько членов вашей команды должны одновременно работать с одними и теми же файлами, то они не могут использовать одну физическую копию файла на всех. Иначе они бы постоянно затирали изменения друг друга. Поэтому команда будет применять специальную систему контроля версий, которая имеет централизованный (или децентрализованный) основной набор файлов. Отдельные разработчики будут выписывать из него, или копировать, нужные файлы, которые будут использоваться только этим программистом (что часто именуют помещением в так называемую песочницу). Разработчик будет трудиться над копией кода в своей «песочнице» и периодически отправлять изменения обратно в общее хранилище.
Проблема в том, что слишком часто разработчик, внося измененную версию программы, обнаруживает конфликт своего кода с изменениями, незадолго до этого внесенными другим программистом. В большинстве случаев этот конфликт выявляется сразу же при попытке выгрузить личную копию в общую базу кода, которая перестает компилироваться. Но временами проблемы оказываются более серьезными и скомпилированная программа ведет себя неправильно. Причина в том, что один код был заменен конфликтующим с ним кодом, взятым из другой «песочницы». Все эти проблемы проявятся, когда будет проведена интеграция системы из различных частей, написанных разными программистами.
И вот тут вступает в дело практика непрерывной интеграции: команда должна достаточно часто собирать код и отслеживать ошибки компиляции или сбои модульных тестов. Многие команды настроят сборочный сервер для периодической компиляции кода из хранилища, запуска полученной сборки и уведомления команды, если обнаружатся ошибки. Но создание сервера непрерывной сборки — это лишь одна часть непрерывной интеграции. Непрерывная интеграция означает, что каждый член команды постоянно содержит свою копию исходного кода в актуальном состоянии. Члены команды периодически интегрируют последнюю версию кода из хранилища обратно в свои «песочницы». Команды, применяющие парное программирование, порой пользуются физическим маркером сборки. Это может быть плюшевая или резиновая игрушка (забавная и заметная, чтобы сразу было видно, у кого она находится). Она переходит от пары к паре. Когда пара получает этот символ, наступает ее очередь интегрировать последнюю версию кода из хранилища к себе, исправить все найденные проблемы интеграции, а затем передать маркер сборки следующей паре. Это гарантирует, что проблемы интеграции будут обнаружены на ранних стадиях и исправлены.
3. Практики планирования
Для управления своими проектами XP-команды используют итеративную разработку. Как и в Scrum, практики XP-планирования основаны на большом цикле долгосрочного планирования, который разбит на короткие итерации. В практике недельного цикла XP-команды используют итерации длиной в одну неделю совместно с практикой историй (это то же самое, что и пользовательские истории, о которых вы уже знаете). Каждый цикл начинается с совещания, посвященного планированию, где члены команды проводят обзор достигнутых результатов, работают с клиентами, чтобы выбрать истории для итерации, а затем разбивают их на задачи, которые оцениваются и передаются разработчикам.
Это вам уже знакомо, потому что это очень похоже на scrum-планирование. Действительно, многие XP-команды в точности перенимают практики scrum-планирования (которые считаются популярными гибридами Scrum и ХР, описанными в отчете VersionOne State of Agile, упоминавшемся в главе 2). Закончив планирование, команда посвящает первую часть итерации написанию автоматических тестов для историй и задач, а остальное время итерации пишет код, способный пройти эти тесты. Но вместо процесса самоорганизации некоторые XP-команды помещают все задачи на данную итерацию в очередь. Каждый разработчик берет следующую задачу из этой очереди после завершения текущей. Это гарантирует, что разработчики не выбирают свои любимые задачи и они распределяются равномерно между всеми.
Для долгосрочного планирования XP-команды используют практику квартального цикла. Раз в квартал команда собирается, чтобы проанализировать ход работ над проектом. На этих встречах XP-команды обсуждают темы – те идеи из реального мира, которые они могут использовать, чтобы связать воедино истории своего проекта. Такие дискуссии помогают выяснить, какие истории необходимо добавить в проект, и поддерживают связь команды с реальными проблемами бизнеса, которые должно решить программное обеспечение. Также обсуждаются внутренние и внешние трудности, которые испытывает команда, повторяющиеся ошибки и еще не внесенные исправления. Оцениваются результаты, которых добилась команда, насколько хорошо удалось удовлетворить потребности клиентов и как в целом продвигается проект. Некоторые XP-команды склонны использовать ту же практику ретроспектив, что и scrum-команды.
И последняя из ХР-практик, посвященных планированию, – временной запас. Она позволяет команде добавлять мелкие, менее приоритетные истории в каждый недельный цикл. Во время планирования эти истории разбивают на задачи, но к ним не приступают до конца итерации. И тогда, если команда сталкивается с неожиданными проблемами, она исключает из итерации эти «запасные истории» и все-таки поставляет работающее ПО в конце цикла. Как и в других методах итеративной разработки, XP-команды поставляют в конце итерации только полностью законченный функционал. Это означает, что он работает, все тесты пройдены и его можно продемонстрировать пользователям.
4. Командные практики
XP затрагивает как программирование, так и совместную работу команд. Эта методика включает в себя две основные практики, помогающие командам сплотиться, – «командные практики». Первая – коаллокация, когда команда располагается в одном помещении. Люди в команде работают лучше, когда сидят рядом друг с другом и могут легко коммуницировать. Многие люди не осознают, что, хотя программирование – это индивидуальный труд и зачастую выполняется в одиночку (за исключением парного программирования), работа в команде разработчиков требует высокой социальной активности.
Члены команды постоянно консультируются друг с другом, советуются и предупреждают о возможных проблемах. Если команда располагается в помещении типа open space, такая социализация обеспечивается естественным образом. По поводу того, каким должно быть открытое рабочее пространство, ведется много споров. Чтобы работать эффективно, программисты должны быть защищены от отвлекающих факторов. Многие из них ценят уединенность и размещают свои мониторы так, чтобы проходящие мимо люди не могли видеть экран. Популярное решение этой проблемы – модель планировки офиса «пещеры и поляны», описанная Стюартом Брэндом в книге How Buildings Learn. В его схеме имеются как отдельные, так и общие рабочие места для программистов, которые одной стороной выходят в общий зал со столами для проведения совещаний и компьютерами для работы парами.
Следующая основная практика XP-команд – это информативное рабочее пространство, в котором производственная среда команды устроена таким образом, чтобы важная информация о проекте автоматически передавалась всем участникам. Один из наиболее популярных способов для этого – применение большой доски задач и диаграммы выполняемых работ (диаграммы сгорания), которые висят так, чтобы каждый мог их видеть. Наглядное размещение постоянно обновляемой информации о проекте позволяет каждому члену команды знать, на какой стадии находится проект, и принимать правильные решения. Такие диаграммы и другие способы, которые команда использует для отображения данных, делающие рабочее пространство более информативным, называются излучателями информации. Они автоматически передают текущую информацию о проекте всем, кто на них взглянет.
Большие, наглядные диаграммы – не единственный способ сделать рабочее пространство информативным. Когда у членов команды появляются вопросы, они сталкиваются с проблемами или им необходимо обговорить какие-то детали, они организуют обсуждение. Если такие дискуссии происходят в общем рабочем пространстве, а не в закрытых конференц-залах, то окружающие невольно слышат их и впитывают информацию о происходящем. Когда члены команды автоматически вбирают информацию о проекте – неважно, из диаграмм, разговоров или иным способом, – это называется осмотической коммуникацией. Командам необходимо найти баланс между пользой такой коммуникации и ее отвлекающим влиянием, и XP-команды становятся успешными, если им удается его отыскать.
Почему важны информационные рабочие пространства? Суть в том, чтобы помочь команде принимать лучшие решения и дать ей больше контроля над ходом проекта – подобно тому, как доски задач помогают scrum-командам. Главное, что информация предназначается для всей команды, а не только для ее руководителей или менеджеров. Это демократизирует распространение информации и обеспечивает ею всю команду без какой-либо фильтрации. Чем больше сведений о проекте доступно команде, тем сильнее каждый ее участник может влиять на ход событий.
Фото: pixabay.com
