• В следующий раз, когда вы будете работать допоздна, задумайтесь, что вас заставило задержаться. Можно ли было как-то предотвратить это? Возможно, установленные сроки слишком жесткие? Или в последнюю минуту появилась дополнительная работа?
Признать наличие проблемы и выделить время на ее осознание – вот первый шаг к исправлению ситуации.
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Узнать больше о ценностях и принципах Agile-манифеста и о том, как он был создан, можно в книге Алистера Коберна «Быстрая разработка программного обеспечения» (М.: Лори, 2013).
• Узнать подробнее о значимости итерации и других аспектов agile-управления проектами можно в книге Джима Хайсмита Agile Project Management: Creating Innovative Projects (Addison-Wesley, 2009).
• Узнать больше о сложных задачах, с которыми сталкиваются команды, желающие стать гибкими, и о том, как их преодолеть, можно в книге Майка Кона «Scrum. Гибкая разработка ПО» (М.: Вильямс, 2016).
• Узнать больше о том, как оставить в прошлом командно-административное мышление, можно, прочитав книгу Лиссы Адкинс Coaching Agile Teams (Addison-Wesley, 2010). В настоящее время эта книга готовится к изданию.
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Помогите команде понять, что сверхурочная работа – это причина сокращения объема созданного кода, более того – она ухудшает его качество.
• Поговорите с каждым членом команды о том, какой работой он занимается. Что им движет? Что расстраивает? Чем он руководствуется при принятии решений?
• Попросите каждого участника группы выбрать три agile-принципа, оказывающих на него наибольшее влияние (как негативное, так и позитивное). Люди будут удивлены, что их коллеги выбрали разные принципы. Это поможет найти точки соприкосновения между всеми участниками команды.
• Используйте принципы, общие для всех членов команды, как отправную точку, чтобы выяснить, какие методы наиболее соответствуют мировоззрению команды.
Глава 4. Scrum и самоорганизующиеся команды
Великие принципы, не рождающие действия, являются всего лишь эфемерной субстанцией. И наоборот, конкретные практики при отсутствии руководящих принципов часто используются неадекватно.
Лозунг настольной игры «Отелло» – «Минута на обучение, вся жизнь на совершенствование». Это очень подходит команде, которая учится Scrum. Базовые практики и ценности Scrum просты и легки в применении. Но понять, как они превратятся в результат – лучшее программное обеспечение, – может оказаться непросто.
Правила Scrum просты и легки для понимания, что позволяет многим командам, применяющим agile-методологии, использовать его в качестве отправной точки. Вот основная схема scrum-проекта.
• В scrum-проекте существует три основные роли: владелец продукта, scrum-мастер и член команды. (Мы придаем особую важность понятиям «владелец продукта» и «scrum-мастер», когда речь идет о scrum-ролях.)
• Владелец продукта работает с остальной частью команды, чтобы поддерживать и определять приоритеты функций и требований продуктового бэклога, которые необходимо реализовать.
Рис. 4.1. Базовая схема Scrum
• Программное обеспечение строится с использованием ограниченных по времени итераций, называемых спринтами. В начале каждой такой итерации команда выполняет планирование спринта, чтобы определить, какие функции из бэклога они будут реализовывать. Это называется бэклог спринта. На протяжении спринта команда работает над созданием всех тех функций, которые в него вошли.
• Ежедневно все члены команды участвуют в короткой встрече (Daily Scrum – ежедневный scrum-митинг), чтобы рассказать друг другу о достижениях и обсудить то, что препятствует дальнейшей работе. Каждый человек отвечает на три вопроса: что я сделал с момента последнего ежедневного совещания? Что буду делать вплоть до следующего ежедневного совещания? Какие препятствия есть на моем пути?
• Scrum-мастер поддерживает правильное направление работы над проектом, устраняет препятствия на пути команды и помогает ей, если есть просьбы о помощи. В конце спринта работающее ПО показывают владельцу продукта и стейкхолдерам проекта. Команда проводит одновременно обзор итогов спринта и ретроспективный обзор, чтобы выяснить ошибки. Таким образом удается улучшить сам процесс спринта и качество создания программного продукта в будущем.
Чтобы стать успешной, scrum-команде нужно делать больше, чем просто придерживаться базовой схемы Scrum. Эффективная scrum-команда должна быть самоорганизующейся. В это понятие мы вкладываем тот же смысл, что и Кен Швабер в своей книге Agile Project Management with Scrum (обратите внимание на слова, которые мы выделили курсивом).
Чтобы работать по Scrum, команда должна глубоко и на интуитивном уровне понимать коллективную ответственность и самоорганизацию. Scrum-теорию, методы и правила легко понять. Но пока группа, состоящая из отдельных людей, не взяла на себя коллективное обязательство за создание чего-то материального в течение ограниченного промежутка времени, эти индивидуумы, пожалуй, не овладеют Scrum. Когда же члены команды перестают действовать как многие и принимают на себя обязательства за общие цели, команда становится способной к самоорганизации, может быстро пройти через сложности и на практике реализовать планы.
Цель этой главы – помочь вам «заполучить Scrum», опираясь на идеи из главы 2 и главы 3, то есть научить вас практикам и моделям этой методологии. Мы будем использовать эти практики, чтобы продемонстрировать идеи, стоящие за принципами коллективной ответственности и самоорганизации.
Правила Scrum
В книге Кена Швабера Agile Project Management with Scrum изложены правила Scrum, описывающие основной шаблон scrum-проекта. Вы можете бесплатно скачать правила Scrum на сайте www.scrum.org в формате PDF – это электронная книга The Scrum Guide, написанная Кеном Швабером и Джеффом Сазерлендом. Эти люди создали Scrum и помогли распространить его влияние на остальные направления программирования. Правила должны быть вам хорошо знакомы, потому что многие из них описаны в главe 2 и главе 3. Вот каким правилам следует типичный scrum-проект.
• Каждый спринт начинается с планирования, в котором участвуют scrum-мастер, владелец продукта и остальные члены команды. Встреча разделена на две части, по четыре часа каждая. Владелец продукта заранее выделяет приоритетные направления продуктового бэклога, который состоит из набора позиций, выбранных для разработки потребителями и заинтересованными сторонами. В первой части встречи владелец с командой выбирает элементы бэклога, которые будут поставлены в конце спринта, исходя из их значимости и оценки командой объема работ. Команда обязуется провести презентацию работающего программного обеспечения, включающего все эти элементы бэклога в конце спринта. На это тратится половина отведенного для планирования времени (для 30-дневного спринта это четыре часа, а для более коротких время пропорционально сокращается). В результате команда фиксирует элементы бэклога, одобренные командой на этапе планирования, и использует их в качестве бэклога спринта. Во второй части встречи члены команды (при помощи владельца продукта) знакомятся с индивидуальными заданиями, которые они будут выполнять для фактической реализации этих элементов.
Длина этой части встречи также зависит от длины спринта (но часто занимает меньше времени, чем другая). По окончании планирования выбранные участниками элементы становятся бэклогом спринта.
• Команда проводит scrum-митинг каждый день. Все члены команды (включая scrum-мастера и владельца продукта) обязаны[27] в них участвовать. Заинтересованные лица также могут присутствовать (но только в качестве наблюдателей). Встреча длится не больше 15 минут, поэтому все члены команды должны приходить вовремя. Каждый из них отвечает на три вопроса: что я сделал с момента прошлой встречи? Что буду делать с сегодняшнего дня и до следующей встречи? Какие препятствия есть на моем пути? Все члены команды должны быть краткими. Если ответ требует обсуждения, то ответственные за составление графика немедленно организуют дополнительную встречу.
• Продолжительность любого спринта определяется на совместной встрече. Многие команды планируют спринт на 30 календарных дней, но возможны варианты – некоторые команды выбирают двухнедельные периоды. Во время спринта команда работает над задачами, вошедшими в бэклог спринта. Разработчики могут получить помощь от участников проекта, не входящих в команду, но они не имеют права указывать команде, как надо работать, и должны доверять ей. Если любой член команды в середине спринта обнаружит, что требуется добавочное время или дополнительные элементы бэклога, то, как только станет ясно, что спринт в опасности, нужно уведомить об этом владельца продукта. Владелец продукта – это член команды, который работает с пользователями и стейкхолдерами и оповещает их о ходе проекта. Он использует полученную информацию для коррекции спринта, чтобы он соответствовал реальным возможностям команды. Если же команда считает, что закончит работу до окончания спринта, то она может добавить в бэклог дополнительные позиции. Команда должна актуализировать состояние бэклога спринта и предоставлять к нему доступ остальным членам проектной группы. В экстренной ситуации владелец продукта может завершить спринт раньше и начать планирование нового спринта. Так бывает, если команда понимает, что не может предоставить работающее ПО (например, возникают серьезные технологические, организационные или кадровые проблемы). Но каждый должен знать: прекращение спринта случается редко и имеет крайне негативные последствия для производительности, а также с точки зрения доверия со стороны пользователей и стейкхолдеров.