Гибкие методологии разработки ПО

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

Agile

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

Основные идеи Agile-подхода

• Люди и взаимодействие между ними важнее процессов и инструментов.

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

• Работающий продукт важнее исчерпывающей документации.

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

• Сотрудничество с заказчиком важнее следования условиям договора.

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

• Готовность к изменениям важнее следования изначальному плану.

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

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

Agile — это целое семейство практик, которые можно разделить на две группы: инженерные и процессные.

К процессным относятся Scrum, Kanban, Scaled Agile Framework. Их задача состоит в том, чтобы организовать рабочий процесс и управлять им.

Инженерные — это, например, Lean или Extreme Programming. Они используются инженерами для организации своей работы.

Принципы Agile

Основные принципы Agile отражены в специальном манифесте, который был принят в феврале 2001 г. Agile Manifesto содержит четыре основные идеи и 12 принципов.

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки.
3. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
4. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
5. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
6. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
7. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее.
8. Работающий продукт — основной показатель прогресса.
9. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
10. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
11. Простота — искусство минимизации лишней работы — крайне необходима.
12. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Как видите, почти во всем принципы Agile полностью соответствуют тому, чему нас учит и классическая методология: вовлекать заказчика; частые результаты поставки лучше крупных разовых; самое важное — команда и ее мотивация. Обо всем этом мы уже говорили на страницах нашей книги. Давайте еще больше углубимся и посмотрим детальнее на Scrum, Kanban, XP и Lean.

Scrum

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

Scrum не является процессом, техникой или исчерпывающим методом. Напротив, Scrum — это фреймворк, в котором можно использовать разнообразные процессы и методы.

Основные элементы фреймворка — scrum-команды и связанные с ними роли, события, артефакты и правила. Каждый элемент фреймворка служит определенной цели и является обязательным для успешного использования Scrum.

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

Scrum основан на трех китах: прозрачности, инспекции и адаптации.

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

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

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

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

Scrum предполагает четыре формальных события для инспекции и адаптации:

• планирование спринта;
• ежедневный скрам;
• обзор спринта;
• ретроспектива спринта.

Эти события детально рассмотрены в разделе «События Scrum».

Ценности Scrum

Scrum-команда опирается на следующие ценности:

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

Основные роли

Работа по Scrum подразумевает задействованность в проекте нескольких ролей.

Scrum-мастер (Scrum master) — человек, который отслеживает соблюдение всех ритуалов фреймворка Scrum и помогает команде решать открытые вопросы. В его обязанности входит разрешение внутрикомандных противоречий и защита от отвлекающих факторов.

Тут можно провести аналогию с руководителем проекта, но она будет не совсем верна. В Scrum обязанности классического руководителя проекта делятся между Scrum-мастером и владельцем продукта.

Владелец продукта (Product owner) — человек, который представляет в проекте интересы пользователей и других заинтересованных сторон. Владелец продукта отвечает за формирование и приоритизацию списка известных требований к продукту — бэклога.

Эта роль больше всего похожа на роль спонсора проекта, но с дополнительной ответственностью за приоритеты, итоговый бюджет и сроки.

Команда разработки (Development team) — кросс-функциональная команда проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и др. Идеальный размер команды в Scrum — от трех до девяти человек. Команда отвечает за результат проекта как единый исполнитель. Никто не может вмешиваться в ее работу на всем протяжении спринта.

Scrum-артефакты

Артефакты Scrum отражают работу или ценность, создавая новые возможности для инспекции и адаптации. Они специально разработаны для обеспечения максимальной прозрачности ключевой информации, чтобы все участники процесса обладали одинаковым ее пониманием.

Бэклог продукта (Product backlog) — упорядоченный список известных требований к продукту. Это единственный источник требований к любым необходимым изменениям в продукте. Владелец продукта является ответственным за его бэклог, включая содержимое, доступность и упорядоченность продукта.

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

Бэклог спринта (Sprint backlog) — это набор элементов бэклога продукта, взятых в спринт, плюс план по достижению цели спринта и поставке инкремента продукта. Бэклог спринта — это прогноз команды разработки о том, какая функциональность войдет в следующий инкремент и какая работа необходима для создания готового инкремента.

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

Инкремент (Increment) — это сумма завершенных во время спринта элементов бэклога продукта и всех инкрементов предыдущих спринтов. К концу спринта инкремент должен быть «готов», что подразумевает его соответствие критериям готовности Scrum-команды и готовность к использованию.

Диаграмма «сгорания» задач (Burndown chart) — диаграмма, демонстрирующая количество проделанной и оставшейся работы относительно времени на разработку проекта (рис. 61). При помощи этой диаграммы мы можем спрогнозировать, когда будет завершена работа над всеми задачами, находящимися в бэклоге.

Хотя диаграмма «сгорания» задач не является артефактом Scrum, все же хотелось бы ее отметить. Обратите внимание на сходство с методом освоенного объема, который мы рассмотрели ранее.

События Scrum

Спринт (Sprint) служит ядром Scrum. Это временной отрезок длительностью до месяца, в течение которого создается «готовый», то есть пригодный к использованию и выпуску, инкремент продукта. Желательно сохранять неизменную продолжительность спринта на протяжении всего процесса разработки. Новый спринт начинается сразу после окончания предыдущего.

Спринт похож на этап проекта. Маленький размер этапа обусловлен тем, что при высокой неопределенности мы не уверены, что все делаем верно. Если в конце спринта мы понимаем, что часть работ сделана не так и что-то нужно переделать, то количество исправлений не будет слишком большим.

Планирование спринта (Sprint planning meeting). Планирование происходит в начале новой итерации спринта. В классическом Scrum делается это следующим образом.

• Из бэклога выбираются задачи, которые отдаются на рассмотрение команде.
• Оценивается трудоемкость каждой задачи. Решение не должно занимать более 12 часов (полутора дней). Если требуется, то задача разбивается на подзадачи.
• Члены команды обсуждают каждую задачу и определяют подход к ее решению. Как правило, продолжительность такого совещания ограничена четырьмя часами. Обычно совещание делится на две части. В первой владелец проекта и Scrum-команда выбирают задачи на спринт. Во второй участвует только Scrum-команда, которая определяет технические подходы к решению задач и наполняет бэклог спринта. Как правило, это довольно длинные совещания с оживленными дискуссиями и спорами.
• Команда выбирает задачи, которые успеет сделать за спринт. На основе выбранных задач формируется бэклог спринта.

Ежедневное совещание (Daily Scrum meeting). Есть несколько правил проведения ежедневных Scrum-встреч: они всегда начинаются вовремя, длятся не более 15 минут и проводятся в одном и том же месте на протяжении спринта.

Во время совещания каждый член команды отвечает на три вопроса:

1. Что я сделал со времени последнего совещания, чтобы помочь команде разработки достичь цели спринта?
2. Что я планирую делать сегодня, чтобы помочь команде достичь цели спринта?
3. Вижу ли я препятствия для себя или команды, которые могли бы затруднить разработку? (Если в ответе на этот вопрос озвучиваются проблемы, то над их решением думает уже Scrum-мастер. Как правило, решения таких затруднений ищут вне совещания, а в поиске задействованы те, кого проблема может затронуть непосредственно.)

Обзор спринта (Sprint review meeting). Обзор проводится в конце спринта и нужен для того, чтобы показать итог работы команды за итерацию. Команда демонстрирует прирост функциональности продукта его владельцу и всем заинтересованным лицам. По результату обзора спринта возможна адаптация бэклога.

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

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

Ретроспектива спринта (Sprint retrospective meeting). Ретроспективное совещание — это встреча, которая проходит в самом конце спринта и подводит его итоги. Как правило, продолжительность такого совещания не превышает трех часов. В течение этого времени члены команды:

• высказывают свое мнение о прошедшем спринте и отвечают на два основных вопроса: «Что в нем было сделано хорошо?» и «Что нужно улучшить в следующий раз?»;
• улучшают процесс разработки: решают вопросы и фиксируют удачные решения.

В Juno мы попробовали несколько форматов ретроспектив. Нам нравится вариант с использованием карточек Кроуфорда. Суть в том, чтобы попросить членов команды взять четыре стикера, на двух написать, что понравилось в ходе спринта, а еще на двух — что можно улучшить. Затем все перечисленное выписывается на доску либо стикеры наклеиваются на нее (рис. 62).

После общего изучения получившейся картины каждый член команды снова берет два стикера и пишет на них те меры, которые нужно предпринять в следующем спринте, чтобы поддержать хорошую ситуацию или исправить ее, если все печально. Любопытный момент заключается в том, что на одном стикере нужно написать пожелания для любого члена команды (или для всей команды сразу), а на другом — пожелания для себя, ответив на вопрос: «Что сделаю именно я, чтобы стало лучше?» (рис. 63).

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

Как выглядит рабочий процесс по Scrum

Владелец продукта формирует бэклог продукта или проекта, который содержит в себе задачи в виде User stories. Каждая из них содержит описание того, что нужно сделать, и критерии приемки. Это очень похоже на ИСР, но есть отличие: задачи в бэклоге приоритизированы. Та, что наверху, — самая важная на данный момент. Приоритизируя задачи, владелец продукта определяет то, что важно для бизнеса именно сейчас (рис. 64).

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

В ходе спринта каждый день команды начинается с ежедневного Scrum-митинга. Он очень похож на утреннюю планерку: собрание длится около 15 минут и всегда проходит стоя. Благодаря этому все хотят закончить его побыстрее, поэтому говорят четко и по делу. В ходе митинга каждый член команды должен ответить на три вопроса, которые мы упоминали выше. Роль Scrum-мастера в данном случае напоминает роль менеджера проекта: он собирает информацию, чтобы решать эти самые возникающие проблемы. Scrum-митинг — это ритуал, поэтому важно всегда проводить его в одно и то же время и в одном и том же месте.

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

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

Kanban

Kanban в переводе с японского — «сигнальная доска». Очень часто именно эти доски люди принимают за Kanban, даже не пытаясь копнуть немного глубже и разобраться, насколько он прекрасен.

Как и в случае со Scrum, Kanban — это не конкретная методология, процесс или набор инструментов. Это система ценностей, которая помогает стабилизировать производство, в том числе и разработку ПО, за счет визуализации незавершенной работы, выявления «бутылочных горлышек» и постоянного совершенствования процессов. Применение методологий Kanban очень часто идет рука об руку с принципами теории ограничений, которую идеально описал в своих книгах Элияху Голдратт («Цель»), а его последователи переложили в историю, близкую каждому, кто посвятил свою карьеру информационным технологиям, и связали с такой трендовой в наше время философией, как DevOps, в романе The Phoenix project.

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

Итак, четыре основных принципа Kanban.

1. Визуализация процесса разработки. Одно из основных достоинств Kanban заключается в том, что с его помощью можно визуализировать всю незавершенную работу, что, в свою очередь, дает вам наглядное понимание потоков работ и их ограничений. Для того чтобы начать работать по Kanban, вам понадобятся карточки и доска. Обычно для физических досок в качестве карточек используют стикеры (Post-it notes). Каждая задача записывается на отдельном стикере, который затем помещается на доску, расчерченную на столбцы. Каждый столбец соответствует этапу в рамках вашего процесса разработки; в производстве колонки могут быть эквивалентны узлам обработки или станкам. Главное заблуждение — принимать в качестве «узла» конкретного человека, так как он может выполнять сразу несколько ролей и вместо упрощения потоков производства у вас может получиться «порция спагетти». В самом простом случае столбцов будет три: «Бэклог», «В разработке», «Сделано». По мере работы над задачей карточка продвигается по колонкам от «Бэклога» до «Сделано». В своей работе мы использовали такие колонки:

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

Доски могут быть как физические на стене в офисе, так и электронные в специализированных сервисах, например в Trello или Jira. Задачи продвигаются по колонкам слева направо. Правда, иногда бывает движение и в обратную сторону — к примеру, если в ходе проверки кода выяснилось, что требуется доработка. Важно понимать, что естественным является только движение слева направо. Любое движение в обратную сторону должно приравниваться к браку и, следовательно, подвергаться анализу с целью устранения.

Обратите внимание на приведенную выше схему. Наверху нашей доски есть строка (иначе ее называют «плавательная дорожка» — от англ. swimlane) «Срочно», куда мы помещаем срочные задачи, которые нужно завершить в первую очередь. Такой подход таит в себе ловушку: если злоупотреблять этой строкой, то постепенно туда могут перекочевать все ваши задачи и вы опять вернетесь к вопросу «Как приоритизировать работу». Поэтому рекомендуем вам заранее договориться о правилах приоритизации задач.

Визуализация Kanban — это очень здорово. Так приятно передвигать задачу в следующую колонку по мере завершения очередного этапа работ. Кроме того, она показывает, когда на пути завал (скопление задач в одной колонке) и пора остановиться и разобраться, что пошло не так.

2. Ограничение Work in Progress (WIP). Это количество задач, выполняемых одновременно на каждом этапе разработки. Проще говоря, мы определяем максимальное количество задач, которое можем выполнить на одном этапе. Ограничения позволяют нам избежать тех самых завалов. Представьте себе мост, по которому спокойно проезжают машины со скоростью 80 км/ч при 70%-ной загрузке. Если же загрузка вырастает до 80%, то скорость падает до 60 км/ч, при 90%-ной загрузке скорость составит всего 20 км/ч, а когда загрузка приближается к 100%, движение практически останавливается. По сути, при разработке это правило действует так же: чем меньше у исполнителя параллельных задач, тем быстрее он выполняет свою работу. Быстро и качественно справляться можно только тогда, когда ты сфокусирован на небольшом количестве задач, а в идеале — на одной. Если параллельно вести десяток дел, то время выполнения каждого из них серьезно увеличивается. Например, если тестировщик вдруг заметил баг, а разработчик занялся другой задачей, не дожидаясь завершения проверки, то это окажет значительное влияние на время, за которое будет завершена первая задача.

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

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

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

Работа с «бутылочными горлышками» помогает видеть проблемные места и итерационно улучшать работу над самым медленным шагом, что, в свою очередь, ускоряет весь процесс.

4. Измерение времени цикла. Главная метрика эффективности при использовании Kanban — это скорость, с которой задача «пролетает» из «Бэклога» в «Готово». Поэтому важно измерять среднее время на выполнение одной задачи и постоянно оптимизировать процесс, чтобы сократить его. Отслеживать скорость можно при помощи контрольной карты — это метрика, которая указывает среднее время прохождения задачи по доске. Хорошо, если каждый месяц скорость немного возрастает.

Выглядит эта метрика так (рис. 66).

Точки — время, за которое выполнялись задачи.

Прямая линия — среднее время выполнения задач за период времени, выбранный для отчета.

Волнистая линия — скользящее среднее, показатель изменения скорости прохождения задачи по доске со временем. В нашем примере скользящее среднее уменьшается. Это очень хорошо и свидетельствует о постоянном улучшении процесса.

Светло-серая область — стандартное отклонение. Оно показывает, насколько предсказуемо время выполнения задач.

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

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

Extreme Programming

От управленческого Agile перейдем к инженерному. Экстремальное программирование (Extreme Programming, XP), как и большинство других гибких методологий, — скорее философия, чем набор инструментов.

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

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

Согласно первому изданию книги Extreme Programming Explained, выделяют четыре группы основных приемов экстремального программирования.

1. Короткий цикл обратной связи (Fine-scale feedback). Разработка ПО является диалогом между возможностями и желаниями, при этом меняется и то, и другое. В этих условиях нужно искать баланс между требованиями бизнеса, техническими возможностями и качеством. Владелец продукта или заказчик работают напрямую с командой и всегда доступны для вопросов и диалога.

2. Процесс разработки непрерывный, а не пакетный. Если есть хороший инструментарий по сборке, автоматическому тестированию и выпуску в продакшн, то публиковать новый функционал можно по его готовности частыми небольшими релизами. При этом каждая строчка кода может попасть в релиз почти сразу после написания. Чтобы это стало реальностью, нужен хорошо подготовленный инструментарий непрерывной интеграции (Continuous integration).

Команда непрерывно осуществляет рефакторинг и улучшение дизайна, архитектуры продукта, модулей системы и процесса разработки. Хорошим процентным соотношением считается 70 на 30: 70% времени команда работает над задачами бизнеса, а 30% — над рефакторингом и устранением дефектов.

3. Простота (Simple design) против избыточного проектирования. Как ни странно это прозвучит, но очень легко сделать что-либо сложным. Придумать действительно красивое и простое решение всегда тяжело: это требует времени. Французский ученый и философ Блез Паскаль заметил: «Я пишу длинно, потому что у меня нет времени написать коротко».

С точки зрения проекта это означает, что его суть должна умещаться в одну-две фразы или выражаться в емком образе, как миссия компании.

Для упрощения работы командами используются единые стандарты по написанию кода и автоматические инструменты для проверки соответствия этим стандартам.

4. Социальная защищенность программистов (Programmer welfare). Команда должна уметь поддерживать высокий рабочий темп на неопределенном временном промежутке. И речь идет не о неделях, а о месяцах и даже годах. Поэтому очень важно соблюдать баланс «работа — жизнь». У разработчиков должен быть нормальный рабочий график, чтобы они не «сгорали».

Все эти четыре группы приемов не только верны в теории, но и на практике используются в IT. Они продиктованы здравым смыслом и опытом.

Теперь давайте посмотрим на Lean-подход, который очень хорошо дополняет Extreme Programming.

Lean

Методология Lean («Бережливое производство») родилась в производственной сфере. Это произошло потому, что нужно было устранить из производственной цепочки шаги, которые не добавляли ценности итоговому продукту и за которые клиент не хотел платить. Понятие «lean» появилось в 1980-х гг. Как правило, компании, применяющие Lean, характеризуются культурой непрерывного совершенствования, которая проявляется и в организации как таковой, и на базовом операционном уровне.

Базовым принципом мышления в стиле Lean является создание ценности. Действие, создающее ценность, должно соответствовать трем критериям:

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

Если одно из требований не выполняется, то считается, что действие не создает ценности.

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

Lean базируется на шести принципах.

1. Исключение затратных процессов и продуктов разработки. Фокусироваться нужно на основных функциях продукта, которые необходимы большинству пользователей. Не стоит тратить время на эксклюзивные свойства/функционал, востребованные небольшим числом пользователей. Более того, если какими-либо функциями мало пользуются, то их нужно убирать из продукта. Сопровождение этих функций требует денег, а наличие в кодовой базе замедляет разработку.

Дефектов быть не должно. Зачем тратить время и нервы на устранение дефектов в готовом продукте? Лучше потратить чуть больше времени, но написать код качественно с первого раза.

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

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

Зачем работать над детальной документацией требований, если ее никто не читает и она мгновенно устаревает в процессе?

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

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

3. Принимать решения как можно позже. Если у нас есть возможность отложить принятие решения, то лучше это сделать. Почему? Чем больше удалось собрать информации, тем выше будет качество принятого решения. Следовательно, чем позже вы принимаете решение, тем больше у вас будет информации и тем более верным оно будет.

4. Поставлять как можно раньше. Тот же принцип, что и в Extreme Programming. Предельно быстрая доставка продукта заказчику и короткие итерации, создающие ценность. Оперативная обратная связь.

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

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

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

Выводы

Классический подход и Agile — это набор инструментов менеджера. Все больше проектов сочетают в себе разные инструменты.

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

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

Нам нравится следующая концепция: «Быть Agile — это не слепое следование какой-либо методологии, это мировоззрение, в основе которого — постоянное совершенствование». К сожалению (или к счастью), в нашей практике не было ни одного проекта, выполненного от и до в соответствии с какой-либо методологией. Каждый раз это череда проб и ошибок: что-то подходит и остается в работе надолго, что-то не подходит, и тогда приходится искать работающие инструменты дальше.

Основная идея состоит в том, что не нужно пытаться найти идеальное решение — «серебряную пулю». Нужно быть открытым к изменениям, не бояться пробовать что-то новое. Шаблоны и наработки нужны, они сильно экономят время, но это не панацея.

И вот мы подошли к главному вопросу: как узнать, какую же методологию выбрать для проекта? Об этом мы поговорим дальше.

Отправить