Постигая Agile. Ценности, принципы, методологии

Понимание ценностей Agile

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

В системе Agile есть четыре основные ценности, отраженные в «Манифесте гибкой разработки ПО».

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

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

Agile-принципы

Помимо четырех ценностей, система Agile имеет 12 принципов.

В приоритете команды — удовлетворение нужд заказчика. Увы, заказчик далеко не всегда знает, что именно ему нужно. Поэтому в задачу команды входит как можно быстрее разработать первую рабочую модель продукта и показать ее заказчику. Это даст обратную связь и покажет, куда двигаться дальше.
Всегда должна быть возможность изменить продукт на любой стадии разработки. Обстоятельства порой меняются резко и непредсказуемо. И еще вчера нужный и актуальный продукт сегодня может оказаться невостребованным. Поэтому команда должна быть готова в любой момент внести изменения в продукт. Каждый должен понимать, почему возникла необходимость в изменениях. И помнить, что лучше доработать и получить хороший продукт, чем ничего не менять и получить ненужный.
Критерий прогресса продукта — его рабочая модель. Процесс разработки делится на циклические шаги — итерации. В ходе одной итерации команда улучшает рабочую модель продукта и сразу показывает результат заказчику. Он видит ход работы своими глазами и дает обратную связь. Команда усваивает эту информацию и переходит к следующей итерации.
Рабочую модель необходимо обновлять как можно чаще. Это позволит учитывать обстоятельства текущего момента и вовремя вносить нужные изменения.
Встреча членов команды — самый эффективный способ передачи информации. Документация не заменит личное общение. Одни и те же пункты в документах могут по-разному понять разные члены команды, заказчик или руководитель. Поэтому прямое общение при встрече так важно. В его ходе можно достичь общего видения продукта.
Команда разработки и заказчик работают над продуктом вместе. Совместная работа позволяет экономить время и ресурсы. Заказчик видит, как продвигается разработка и может своевременно оценивать ее и реагировать. Чем меньше у заказчика контактов с командой, тем позже поступает обратная связь. А внесение изменений на более позднем этапе дороже и трудозатратнее.
Мотивированные компетентные сотрудники — двигатель проектов. Достаточно обеспечить их всем необходимым и позволить сделать свою работу. Они должны трудиться, находясь в своей среде, заниматься тем, что лучше всего умеют, и получать за это достойное вознаграждение. По отношению к любому сотруднику необходимо проявлять доверие. При этом каждый должен осознавать степень своей ответственности за продукт. Доверительная атмосфера благотворно влияет на работу. А обилие документации и следование букве документа, напротив, создают препятствия для хорошей работы.
Работать нужно в одном темпе, не снижая, но и не увеличивая его. Необходимо задавать реальные цели и сроки, чтобы команде не пришлось перерабатывать. Сверхурочная работа на пределе сил не сможет долго продолжаться. Она вымотает команду, и показатели эффективности вскоре резко упадут. При этом люди потратят много сил и нервов, столкнутся с эмоциональным выгоранием.
Поддерживайте высокое качество работы на всех этапах. Лучше сразу исправлять мелкие недочеты, чем ждать, когда они накопятся и станут большими ошибками. На каждом этапе работы следует проверять продукт на наличие проблем.
Не усложняйте. Чем проще устройство продукта, тем он надежнее. Чем сложнее конструкция, тем больше вероятность поломки отдельных ее деталей и тем сложнее ее починить. К тому же простое решение экономит время и средства.
Лучшие решения появляются в самоорганизующихся командах. Члены таких команд принимают решения сообща по ходу продвижения работы. План не спускается сверху и не составляется кем-то одним. Каждый вносит свою долю в его разработку.
Команда всегда старается проверять и корректировать свои действия, чтобы развиваться. Это касается и первоначального плана. Если текущая работа показывает, что план неэффективен, члены самоорганизующейся команды сообща его корректируют или разрабатывают новый. Также каждый сотрудник должен проверять себя и других членов команды и честно указывать на замеченные недочеты.

Метод Scrum

Scrum — это особая модель разработки продукта. Scrum-команда имеет определенную структуру. В нее обязательно входит заказчик продукта, а ведущую роль играет scrum-мастер. Он направляет команду по нужному пути, старается устранить препятствия в работе и помочь по мере надобности каждому сотруднику.

Работа в scrum-проекте делится на равные отрезки — спринты. Перед началом спринта команда планирует, что именно намеревается сделать на этом этапе. Заказчик составляет список функций или характеристик, которыми должен обладать продукт. Scrum-мастер выбирает из них нужное количество, которое можно сделать за один спринт. Так формируется список целей, который называется бэклогом спринта. Потом каждому участнику команды даются индивидуальные задания на текущий спринт.

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

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

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

Самоорганизующиеся команды

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

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

Заказчик дает направление работы и высказывает требования к продукту. Scrum-мастер помогает команде работать максимально эффективно. Но сам ход работы постоянно обсуждается и корректируется всеми членами команды на ежедневных митингах.

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

Другие важные особенности самоорганизующихся команд:

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

Доска задач

Важнейшим инструментом в Scrum является доска задач. Она состоит из трех столбцов: «сделать», «в процессе» и «сделано». К доске задач имеет доступ каждый сотрудник команды.

В начале спринта все задачи находятся в столбце «сделать». Они представлены в виде карточек. Есть отдельные карточки для обозначения целей спринта и для обозначения конкретных задач для достижения этих целей.

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

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

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

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

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

Метод XP

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

Практики XP можно разделить на четыре группы.

Практики программирования

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

Практики интеграции

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

Практики планирования

Недельный цикл: суть работы похожа на спринты в методе Scrum. В течение недели команда работает над конкретными задачами. Задачи ставятся в очередь по приоритетности. Как только программист закончил с одной, он берет следующую в очереди.
Квартальный цикл: используется для долгосрочного планирования. Раз в квартал команда проводит совещание, на котором определяются долгосрочные цели и подводятся итоги уже сделанной работы.
Временной запас: к приоритетным задачам добавляют менее приоритетные. За них берутся, если к концу цикла все основные задачи сделаны. Если же возникли трудности и приоритетные задачи не выполняются вовремя, то мелкие задачи убирают из плана.

Командные практики

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

Практики работают лучше всего, когда команда разделяет ценности XP. Вот они:

коммуникация;
простота;
обратная связь;
уважение.

Главная цель метода XP — создать гибкую программу, которую легко изменить, не нарушая ее работоспособности.

Lean — бережливое мышление

Scrum и XP — это система практик, которые работают, даже если вы не придерживаетесь соответствующих принципов. В этом случае они работают хуже, но все же работают. Lean отличается от этих систем потому, что это прежде всего тип мышления. Термин «Lean» подразумевает бережливость.

Вот основные ценности Lean:

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

Бережливость подразумевает грамотное распределение ресурсов. Команда должна работать только над тем, что приносит ценность. Это определяется в начале каждого цикла работы или спринта и вносится в бэклог. Любая работа над чем-то, что не входит в бэклог, — это потери. Такими потерями могут стать:

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

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

Другой важный принцип бережливости — стремление к целостности продукта. Именно она приносит максимальную ценность.

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

Столь же важно целостно рассматривать саму работу над продуктом. У каждого в команде есть свое понимание ценности работы. Иногда менеджеры видят ситуацию несколько иначе, чем разработчики. Для целостностного понимания ситуации необходимы единые метрики. Они должны быть основаны на объективных факторах: времени, выполненных пунктах бэклога, количестве положительных и отрицательных отзывов.

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

Канбан — метод постоянного совершенствования

Канбан является продолжением Lean-подхода. Это методика совершенствования работы Agile-команд. Если ваша работа зашла в тупик, показатели падают, а вы то и дело сталкиваетесь с одними и теми же ошибками — Канбан вам поможет.

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

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

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

Необходимо выделить эти элементы и поместить их в виде стикеров на специальную доску. Она называется канбан-доска. Она отличается от доски задач в методе Scrum. Ее основные единицы — не задачи, а именно рабочие элементы. Канбан-доска помогает увидеть процесс работы более масштабно. Она показывает не только работу команды, но и состояние рабочего элемента до попадания в команду и после работы.

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

WIP-лимит

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

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

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

Все Agile-методики дополняют друг друга. Вы можете использовать их вместе или по отдельности. Главное здесь — не методы или практики, а перемена в мышлении. Важно разделять ценности Agile и соблюдать его принципы. Только это сделает результат максимально эффективным. Внедрить систему помогают Agile-коучи.