Скрам. Гибкое управление продуктом и бизнесом Швабер Кен
Результатом планирования становится бэклог спринта, состоящий из выбранных элементов бэклога продукта и плана их реализации, который, в свою очередь, состоит из задач, их оценки и выбранных на ближайшие два-три дня исполнителей, чтобы участники команды могли приступить в разработке функциональности. Фактическая работа может отличаться от планируемой объемом и сложностью, поэтому список задач может быть неполным, но он должен быть достаточным, чтобы команда могла прогнозировать объем работы, который сможет выполнить за предстоящий спринт. Часто команда разработки более тщательно детализирует работу, которую будет выполнять в первые дни спринта. Для этого она разделяет работу на более мелкие задачи, обычно длительностью не более одного дня.
Владелец продукта должен быть доступен для команды, чтобы ответить на вопросы, которые могут возникнуть у команды о бэклоге продукта, и прояснить смысл выбранных элементов. Если у команды разработки набирается слишком много или слишком мало работы, владелец продукта может пойти на компромисс: команда разработки вместе с владельцем продукта корректируют количество и состав выбранных элементов бэклога продукта для достижения запланированной цели спринта. К концу планирования спринта команда разработки должна уметь объяснить владельцу продукта и скрам-мастеру, как она намерена работать в рамках самоорганизации, чтобы достичь цели спринта и создать ожидаемый готовый к поставке инкремент продукта.
Ежедневный скрам
Ежедневный скрам – это ежедневное событие команды разработки длительностью не более 15 минут, где она планирует свою работу на ближайшие 24 часа. Длительность не зависит от количества участников команды.
Команда разработки использует это событие:
для инспектирования своего продвижения к цели спринта;
для отслеживания прогресса по работе над бэклогом спринта;
для понимания, успевает ли она завершить задачи спринта в срок.
Проведение ежедневного скрама увеличивает вероятность того, что команда разработки достигнет цели спринта. Каждый день участники команды разработки должны понимать, как они собираются работать вместе в качестве самоорганизующейся команды для достижения цели спринта и создания ожидаемого готового к поставке инкремента продукта к концу спринта. Анализируя то, что сделано за последние сутки, и прогнозируя оставшуюся работу текущего спринта, команда разработки оптимизирует взаимодействие между своими участниками и повышает свою производительность.
Для упрощения ежедневный скрам проводится каждый день в одно и то же время, в одном и том же месте. Проводить ежедневный скрам следует в начале дня так, чтобы по прибытии на работу первым делом участники команды подумали о том, что они делали накануне и что планируют сделать сегодня.
Скрам-мастер следит, чтобы событие команды разработки состоялось, но за проведение ежедневного скрама отвечает сама команда. Скрам-мастер обучает команду разработки проводить ежедневный скрам за 15 минут или быстрее.
Участники команды должны приходить вовремя. Скрам-мастер начинает ежедневный скрам в назначенное время, независимо от того, сколько членов команды разработки присутствует. Любой опоздавший участник при появлении незамедлительно выплачивает $1 скрам-мастеру.
Ежедневный скрам – это внутреннее событие команды разработки, на котором должны присутствовать все участники команды разработки. Если по какой-либо причине участник команды не может присутствовать лично, то он либо подключается по телефону, либо обеспечивает, чтобы другой участник рассказал о его прогрессе.
Если на событии присутствуют и другие люди, скрам-мастер следит, чтобы они не принимали активного участия. Эти люди должны стоять на периферии области проведения ежедневного скрама, чтобы не мешать событию. Им запрещается разговаривать, делать замечания, кривить лицо или иным образом обозначать свое присутствие и мнение. Им не разрешается разговаривать с участниками команды после ежедневного скрама для получения разъяснений или давать советы и рекомендации. Если будет присутствовать слишком много цыплят, скрам-мастер может ограничить посещаемость, чтобы событие оставалось упорядоченным и сфокусированным.
Те, кто не соблюдает вышеуказанные правила, могут быть исключены из собрания (цыплята) или удалены из команды разработки (поросята).
Команда сама определяет формат ежедневного скрама, но акцент всегда остается на достижении цели спринта. Какие-то команды организуют дискуссию, какие-то используют вопросы, например:
Что я сделал со времени последнего ежедневного скрама, что помогло команде разработки приблизиться к цели спринта?
Что я сделаю до следующего ежедневного скрама, чтобы помочь команде разработки достичь цели спринта?
Вижу ли я какие-либо препятствия, которые могут помешать мне или команде разработки достичь цели спринта?
Участники команды разработки говорят по очереди, пока не выскажутся все. Они не должны отвлекаться на сторонние вопросы, архитектурные решения, обсуждение проблем или сплетен. Скрам-мастер несет ответственность за быстрое перемещение слова от человека к человеку.
В любой момент времени в течение ежедневного скрама говорит один и только один человек – тот, кто сообщает о своем прогрессе. Все остальные слушают без посторонних разговоров. Если участник команды разработки сообщает о том, что представляет интерес для нескольких других участников или что он нуждается в помощи с их стороны, то они могут договориться о встрече всех заинтересованных сторон после ежедневного скрама. Часто сразу после ежедневного скрама команда разработки в полном составе или ее отдельные участники встречаются для более детального обсуждения или для изменения либо перепланирования оставшейся в спринте работы.
Ежедневный скрам улучшает коммуникации, делает другие встречи ненужными, помогает выявить препятствия в разработке, которые необходимо устранить. Он способствует быстрому принятию решений и поощряет его, повышает уровень знаний команды разработки. Это ключевое событие для инспекции и адаптации.
Спринт
Спринт служит ядром скрама. Спринт – временной отрезок длительностью месяц или меньше, за который команда разработки создает что-то существенное для владельца продукта и заинтересованных лиц, при этом доводит инкремент продукта до состояния, когда он потенциально может быть поставлен.
Спринт состоит из планирования спринта, ежедневного скрама, разработки, обзора спринта и ретроспективы спринта. Каждый спринт можно считать проектом, который нужен для достижения целей. Каждый спринт включает цель, концепцию реализации с адаптивным планом по ее достижению, исполняемую в спринте работу и инкрмент продукта как результат этой работы. Спринты облегчают планирование благодаря инспекции и адаптации прогресса по отношению к цели спринта как минимум раз в месяц. Они ограничивают стоимость рисков разработки месяцем работы.
Максимальная продолжительность спринта – один календарный месяц. При большем сроке планирования возможны изменение целей, увеличение комплексности и рост рисков. За месяц количество работы не становится большим настолько, что требуются артефакты и документы, поддерживающие работу команды. Это также максимальное время, в течение которого большинство заинтересованных лиц не потеряют интерес к результатам работы команды и уверенность в том, что команда разработки делает для них что-то значимое. Желательно сохранять неизменную продолжительность спринта на протяжении всего процесса разработки.
Новый спринт начинается сразу после окончания предыдущего. Во время планирования спринта команда прогнозирует реализацию части бэклога продукта. Никто не может изменять этот бэклог во время спринта. Взятые в спринт элементы бэклога продукта замораживаются до конца спринта.
Во время спринта:
не допускаются изменения, которые могут поставить под угрозу цель спринта;
качество продукта не должно снижаться;
по мере появления новых знаний объем работ может быть уточнен и заново согласован между владельцем продукта и командой разработки.
Во время спринта команда может обращаться за советами, помощью, информацией и поддержкой к другим лицам. Однако никто не может давать советы, комментарии или указания команде разработки по своей инициативе. Команда полностью самоуправляемая.
У участников команды есть две обязанности во время спринта:
присутствовать на ежедневных скрамах;
поддерживать бэклог спринта в актуальном состоянии и доступным в общей папке на общем сервере.
При обнаружении новых задач они должны сразу же добавляться в бэклог спринта. В этом случае необходимо пересчитать количество оставшейся работы. Если команда понимает, что она может реализовать за спринт больше элементов бэклога продукта, чем было выбрано во время планирования, она может обсудить с владельцем продукта добавление в спринт дополнительных элементов бэклога продукта. Если команда понимает, что не сможет реализовать все взятые в спринт элементы бэклога продукта, она может обсудить с владельцем продукта удаление части элементов из текущего спринта. Если необходимо удалить настолько много элементов, что спринт потеряет свою ценность и значение, владелец продукта может досрочно отменить спринт.
Отмена спринта
Спринт может быть отменен досрочно. Правом на отмену спринта обладает только владелец продукта, хотя на данное решение могут повлиять заинтересованные лица, команда разработки или скрам-мастер. Существует единственное основание для отмены спринта – потеря актуальности цели спринта. Причиной этому могут быть смена направления работы компании, изменение рыночных условий, изменение или неработоспособность технологий. То есть спринт может быть отменен, если он потерял смысл в контексте сложившихся обстоятельств. Но подобные отмены происходят крайне редко благодаря короткой длительности спринтов.
При отмене спринта все завершенные и «готовые» элементы бэклога продукта пересматриваются. Владелец продукта принимает часть работы, представляющую готовый к выпуску инкремент. Все незаконченные элементы бэклога продукта переоцениваются и возвращаются обратно в бэклог продукта. Недоделанная работа по этим элементам быстро теряет ценность, поэтому ее нужно пересматривать и оценивать в новых условиях.
Отмена спринта требует много усилий и ресурсов, так как предполагает переориентацию всех участников, чтобы начать новый спринт и его планирование. Отмены спринта болезненны для скрам-команды, поэтому к ним прибегают крайне редко.
Обзор спринта
Обзор спринта проводится в конце спринта для инспекции инкремента и, по необходимости, адаптации бэклога продукта. В ходе обзора спринта скрам-команда и заинтересованные лица совместно обсуждают, что было сделано за спринт. Эти данные, как и любые изменения бэклога продукта в течение спринта, служат основанием для обсуждения следующих шагов к оптимизации ценности продукта.
Обзор спринта – не статусная встреча, а неформальное событие. На нем проводится демонстрация инкремента продукта для получения обратной связи от заинтересованных лиц и развития сотрудничества. Скрам-мастер заботится о том, чтобы обзор состоялся, а все участники понимали ее цель. Скрам-мастер обучает всех участников укладываться в отведенное на событие время. Для спринтов длительностью один месяц продолжительность события не превышает четырех часов. Чем короче спринт, тем короче его обзор.
В число участников события входят скрам-команда и ключевые заинтересованные лица. Владелец продукта выявляет тех, кто хочет участвовать в обзоре спринта, и приглашает их на событие.
Ниже перечислены ключевые аспекты обзора спринта.
Владелец продукта начинает обзор спринта, представляя цель спринта.
Владелец продукта рассказывает, какие элементы бэклога готовы, а какие нет.
Команда разработки рассказывает о том, что удалось выполнить во время спринта, какие проблемы возникли и как они были решены.
Команда разработки демонстрирует готовую функциональность и отвечает на вопросы заинтересованных лиц об инкременте.
Определение термина «готово» может варьироваться от команды к команде и от организации к организации. Обычно «готово» означает, что функциональность полностью реализована и потенциально может быть установлена или поставлена клиентам и пользователям. Если «готово» имеет другое значение, убедитесь, что владелец продукта и заинтересованные лица это понимают. Неготовая функциональность не может быть представлена. Функциональность должна демонстрироваться на рабочих местах участников команды. Система должна работать на сервере, ближайшем к промышленному, – обычно это сервер интеграционного или приемочного тестирования. Нефункциональные артефакты не могут быть продемонстрированы, за исключением случаев, когда они используются для улучшения понимания демонстрируемой функциональности. Такие артефакты не могут быть продемонстрированы в качестве рабочего продукта, и их использование должно быть сведено к минимуму, чтобы не запутывать заинтересованных лиц и не начать добиваться от них понимания того, как разрабатываются программные системы.
Владелец продукта описывает текущее состояние бэклога продукта. При необходимости он прогнозирует возможные даты завершения разработки продукта, основываясь на текущих показателях прогресса.
Проводится обзор того, как изменения рынка или использование продукта могли повлиять на порядок элементов бэклога продукта.
Выполняется обзор сроков, бюджета, возможностей и позиций на рынке для будущих релизов или возможностей продукта.
Заинтересованные лица делятся своими впечатлениями, предлагают желаемые изменения бэклога продукта и порядка его элементов. Они могут:
высказывать любые комментарии, замечания или критику в отношении готового к поставке инкремента;
указать функциональные возможности, которые не были реализованы или не соответствуют их ожиданиям, и попросить включить такие функции в бэклог продукта;
предложить любую новую функциональность, которая приходит в голову при демонстрации инкремента, и запросить ее добавление в бэклог продукта для определения порядка.
Владелец продукта на основе полученной обратной связи обсуждает с заинтересованными лицами и командой разработки потенциальную перегруппировку элементов бэклога продукта. Все присутствующие обсуждают, над чем следует работать дальше. Таким образом, обзор спринта предоставляет ценные данные для планирования следующего спринта.
В конце обзора спринта скрам-мастер сообщает место и дату следующего обзора спринта владельцу продукта, команде разработки и всем заинтересованным лицам.
Результатом обзора спринта является пересмотренный бэклог продукта. Он должен ключать в себя элементы, которые могут войти в следующий спринт. Также бэклог продукта может быть изменен, если появились новые бизнес-возможности.
Ретроспектива спринта
Ретроспектива спринта – это возможность для скрам-команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем спринте. Она проводится после обзора спринта и перед планированием следующего спринта. Максимальная продолжительность ретроспективы – три часа для спринта длительностью один месяц. Для более коротких спринтов, как правило, отводится меньше времени.
Цели проведения ретроспективы спринта:
инспекция прошедшего спринта применительно к людям, отношениям, процессам и инструментам. Обнаружение и упорядочение того, что прошло хорошо, и того, что нуждается в улучшении;
создание плана внедрения улучшений в процесс работы скрам-команды.
В событии участвуют только команда разработки, скрам-мастер и владелец продукта. Скрам-мастер убеждается, что событие проходит позитивно и продуктивно, обучает всех участников укладываться в отведенное на событие время. Он принимает участие в ретроспективе наравне с другими участниками команды, но продолжает нести ответственность за процесс, правила и практики скрама.
Ретроспектива может проходить в разных форматах. Например, скрам-мастер может попросить всех участников ответить на два вопроса:
Что было хорошо во время последнего спринта?
Что можно улучшить в следующем спринте?
Скрам-мастер записывает ответы в сводной форме. Затем все участники решают, в каком порядке будут обсуждать потенциальные улучшения. Скрам-мастер побуждает скрам-команду улучшать процесс разработки и практики в рамках фреймворка скрама. Это необходимо, чтобы в следующем спринте повысить эффективность команды и получать больше удовлетворения от своей работы.
Каждую ретроспективу спринта скрам-команда планирует действия для улучшения качества продукта, совершенствуя рабочий процесс или адаптируя определение готовности элементов бэклога продукта, если это необходимо и не противоречит спецификации продукта и стандартам организации. Конкретные действия по улучшению работы и продукта, которые команда решила выполнить в следующем спринте, должны быть добавлены в бэклог продукта в качестве нефункциональных требований с высоким приоритетом. Ретроспективы, которые не приводят к изменениям, бесполезны, они удручают и огорчают. К концу ретроспективы скрам-команда должна запланировать конкретные улучшения, которые она реализует в следующем спринте. Реализация этих улучшений – это и есть адаптация скрам-команды. Производить улучшения можно в любое время спринта, а ретроспектива спринта – формальная возможность сфокусироваться на инспекции и адаптации.
Приложение Б
Определения
Бэклог продукта
Упорядоченный список известных требований к продукту. Это единственный источник любых необходимых изменений продукта. Он может содержать новые характеристики или новые функции продукта, требования, информацию о путях усовершенствования продукта, обнаруженные дефекты.
Изменения в бизнес-требованиях, рыночных условиях или технологиях могут привести к изменениям в бэклоге продукта. Поскольку требования постоянно меняются, бэклог продукта остается живым артефактом.
Бэклог спринта
Набор элементов бэклога продукта, взятых в спринт, плюс план по достижению цели спринта и поставке инкремента продукта. Бэклог спринта – это прогноз команды разработки о том, какая функциональность войдет в следующий инкремент и какая работа необходима для создания готового инкремента.
Владелец продукта
Сотрудник, ответственный за управление бэклогом продукта с целью максимизации получаемой от продукта или проекта ценности. Владелец продукта представляет для команды разработки интересы всех заинтересованных лиц проекта.
Готово
Определение завершенной работы, согласованное всеми участвующими сторонами и соответствующее стандартам, нормативным документам, распоряжениям и правилам компании. Когда что-то называется «готовым» на ежедневном скраме или демонстрируется как «готовое» на обзоре спринта, оно должно полностью соответствовать этому согласованному определению.
Готовый к поставке инкремент продукта
Полностью разработанный инкремент продукта, содержащий все части завершенного продукта, за исключением элементов бэклога продукта, которые команда взяла в текущий спринт. Инкремент должен быть готов к использованию и поставке вне зависимости от положительного или отрицательного решения владельца продукта о его поставке.
График сгорания
Тренд уменьшения объема оставшейся в спринте, релизе или продукте работы во времени. Источником сырых данных для графика является бэклог спринта или бэклог продукта. По горизонтальной оси – интервалы времени в днях спринта или спринтах создания продукта, по вертикальной – оставшаяся работа.
Ежедневный скрам
Короткое 15-минутное ежедневное событие команды разработки, в ходе которого участники команды синхронизируют свою работу, достигнутый прогресс, планы на ближайшие 24 часа и сообщают о любых препятствиях, которые должны быть устранены скрам-мастером.
Задача бэклога спринта
Одна из задач, которые, по мнению команды разработки, необходимо выполнить, чтобы превратить взятые в спринт элементы бэклога продукта в функциональные возможности системы.
Заинтересованное лицо
Любой человек, тем или иным образом заинтересованный в ходе или результатах проекта. Например, потому, что он его финансировал, или станет использовать продукт, или будет затронут проектом.
Инкремент
Сумма завершенных во время спринта элементов бэклога продукта и всех инкрементов предыдущих спринтов. К концу спринта инкремент должен быть «готов» в соответствии с определением готовности скрам-команды.
Итерация
Один цикл в рамках проекта, отрезок времени длительностью один месяц или меньше, называемый спринтом.
Команда разработки
Кросс-функциональная группа сотрудников, которая несет ответственность за то, чтобы самостоятельно разрабатывать программное обеспечение в каждом спринте.
Обзор спринта
Событие, на котором команда разработки демонстрирует заинтересованным лицам готовую функциональность и отвечает на их вопросы об инкременте. Могут быть продемонстрированы только готовые функциональные возможности продукта.
Для спринтов длительностью один месяц продолжительность события не превышает четырех часов. Чем короче спринт, тем короче его обзор.
Ограничение по времени
Интервал времени, который не может быть превышен и в течение которого происходит событие или собрание. Например, ежедневный скрам ограничен 15 минутами, по истечении которых он завершается, независимо от достигнутых результатов.
Оценка оставшейся работы
Количество часов, которое, по оценке участника команды, остается для завершения работы над любой задачей. Эта оценка обновляется в конце каждого дня работы над задачами бэклога спринта. Оценка – общее количество оставшихся часов, которые потребуются всем людям, выполняющим работу.
Планирование спринта
Событие, которое инициирует спринт. Для спринта длительностью один месяц планирование должно занимать не более восьми часов, для более коротких спринтов планирование проводится быстрее. В ходе планирования спринта скрам-команда принимает решения по двум темам.
Во-первых, команда разработки определяет, каким будет инкремент продукта в конце спринта. Владелец продукта представляет команде разработки элементы бэклога продукта с наивысшим приоритетом. Команда разработки выбирает, какие из предлагаемых владельцем продукта элементов бэклога продукта она сможет превратить в инкремент.
Вовторых, команда разработки решает, как организовать свою работу, чтобы получить готовый к поставке инкремент. Она детально планирует, как превратить элементы бэклога продукта в работающую функциональность в течение спринта.
Поросенок
Человек, выполняющий одну из трех ролей скрама (участник команды, владелец продукта или скрам-мастер), приверженный проекту, берущий на себя и несущий ответственность за проект и скрам-команду.
Ретроспектива спринта
Событие, на котором скрам-команда инспектирует прошедший спринт применительно к людям, отношениям, процессам и инструментам; определяет, что прошло хорошо, что нуждается в улучшении; создает план внедрения улучшений в процесс работы скрам-команды в следующем спринте.
Максимальная продолжительность ретроспективы – три часа для спринта длительностью один месяц. Для более коротких спринтов отводится меньше времени.
Скрам
Фреймворк, помогающий командам в комплексной среде создавать и поставлять продукты наивысшей с точки зрения клиента и заказчика ценности. Состоит из скрам-команд (команда разработки, владелец продукта, скрам-мастер), событий, артефактов и правил, определенных в «Руководстве по скраму». Скрам – не аббревиатура.
Изначально английский термин «scrum» – схватка – берет начало в регби. Это элемент, применяемый для возобновления игры после незначительного нарушения или остановки. Успешная схватка невозможна без тесной и слаженной командной работы хорошо подготовленных игроков.
Скрам-мастер
Сотрудник, ответственный за процесс скрама, его внедрение, правильную реализацию и максимизацию его преимуществ.
Спринт
Отрезок времени длительностью один месяц или меньше, в течение которого команда превращает взятые в работу элементы бэклога продукта в готовый к поставке инкремент продукта.
Цыпленок
Кто-то заинтересованный в проекте, но не имеющий формальных обязанностей и внутренней ответственности за производимый результат работы. Цыпленок не является участником команды, владельцем продукта или скрам-мастером.
Элементы бэклога продукта
Функциональные и нефункциональные требования, проблемы, дефекты, упорядоченные по важности для бизнеса и зависимостям, а затем оцененные. Каждый элемент бэклога продукта должен содержать описание, номер позиции в бэклоге, оценку объема работы и ценности. Элементы вверху списка обычно лучше детализированы, чем элементы внизу. Чем детальнее и яснее описание элементов бэклога продукта, тем точнее может быть их оценка. В свою очередь, чем ниже находятся элементы в бэклоге продукта, тем меньше они детализированы.
Приложение В
Ресурсы
В следующей таблице перечислены ресурсы, которые могут быть полезны для углубленного понимания скрама. Одни ресурсы являются статическими, например статьи и книги о скраме. Другие содержат материалы, помогающие читателю лучше понять аджайл и процессы скрама. Третьи ресурсы – динамические источники информации об аджайле и скраме: сайты, форумы и группы. Все эти источники информации до сих пор помогают мне все лучше понимать скрам.
Этот список не подразумевался быть полным, а призван предоставить первичный справочный материал любому, кто хочет более глубоко понять скрам.
Приложение Г
Контракты с фиксированной ценой и фиксированной датой
Тони отвечал за разработку и развертывание методологии для EngageX – крупной компании по предоставлению профессиональных услуг. Мы знали друг друга в течение 10 лет, с тех пор как я предоставил EngageX лицензию на программное обеспечение своей компании для автоматизации их методологии. Я был уверен, что Тони будет интересно услышать о скраме, поэтому я позвонил ему и договорился о встрече. Тони – один из самых проницательных людей, знакомых мне, он быстро ухватил идеи и преимущества скрама. Но он хотел знать, как скрам предлагает работать по контрактам с фиксированной ценой и фиксированной датой, которые были неотъемлемой частью деятельности фирмы. Способность оценивать контракты и выполнять их условия согласно расписанию и без превышения цены была критической. Его клиенты хотели, чтобы после описания их проблемы кто-то мог сказать, какими будут затраты на ее решение и в какой срок. В конкурсах потенциальных исполнителей преимущество получает наилучшее сочетание репутации компании, низкой стоимости и ранней даты реализации.
Я вынужден был признаться Тони, что не знаю, как использовать скрам для его бизнеса и запроса. Принцип скрама – «искусство возможностей», а не «вы даете мне то, за что я заплатил, тогда, когда пообещали». В течение нескольких лет после встречи с Тони эта проблема не давала мне покоя. Она крутилась в моей голове, пока я наконец не осознал, что в скраме нет серебряной пули: к контрактам с фиксированной ценой и фиксированным сроком подход точно такой же, как и в любом другом процессе, включая предопределенные тяжеловесные методологии. Если нет способа провести достаточный анализ требований клиента, чтобы понять масштаб проблемы, и достаточное проектирование, чтобы понять сложность архитектуры и количество необходимых артефактов, значит, перед началом использования фреймворка скрама нужно добавить водопадную фазу создания документации. Это ужасно. И какова польза от скрама, если он мог бы работать только в качестве второй фазы водопадного процесса?
Чем больше я думал об этом, тем больше понимал, что, хотя скрам и не может использоваться в полном объеме, EngageX или любая другая организация, заключающая контракты с фиксированной ценой и фиксированной датой, может использовать скрам для получения конкурентных преимуществ при участии в конкурсе предложений от потенциальных исполнителей (requests for proposals, RFP). Описанный ниже и неоднократно использованный подход привел к взаимоотношениям сотрудничества между EngageX и его клиентами, которые впоследствии смогли ощутить преимущества скрама.
Большинство ответов на запросы предложений состоят из заявки, даты исполнения обязательств, квалификации сотрудников и компании, перечисления предыдущих аналогичных контрактов и опыта, используемой методологии разработки и плана в виде высокоуровневых и низкоуровневых диаграмм Ганта. План показывает, какая работа будет выполнена, позволяет определить требуемых сотрудников и оценить стоимость. Чтобы предоставить эту информацию, необходимо проанализировать запрос потенциального клиента, полностью понять и учесть все требования и разработать предварительную архитектуру системы. Когда для участия в конкурсе предложений по договорам с фиксированной ценой и датой используется скрам, эти требования лягут в основу новой части заявки – бэклога продукта. Он позволит потенциальному заказчику увидеть не только то, что все требования были поняты, но и что компания-исполнитель понимает приоритет требований в создании ценности для бизнеса. Наиболее ценные требования, помогающие решить проблемы клиента, окажутся в верхней части списка с высокими приоритетами, а менее полезные требования – в нижней части.
Подавшая заявку фирма покажет клиенту, что она подготовила список требований, упорядоченный в соответствии с ее оценкой ценности и важности функциональных возможностей для бизнес-потребностей клиента. Затем фирма-претендент может сказать, что она произвела такой анализ, потому что ее процесс разработки отличается от процесса большинства других компаний, предоставляющих профессиональные услуги. Вместо поставки системы целиком ближе к дате контракта, она будет наращивать возможности системы инкремент за инкрементом. Фирма предпочитает подход, при котором команда разработки может не реже раза в месяц показывать заказчику то, что она создала за прошедший период, чтобы убедиться, что находится на верном пути и отвечает запрошенным потребностям. Каждый месяц команда фирмы собирается вместе с клиентом и инспектирует только что созданную функциональность.
Далее фирма-кандидат может указать на дополнительные преимущества такого подхода. Поскольку команда разработки превращает самые важные требования в бизнес-функциональность итерациями, если из-за меняющихся рыночных условий заказчик захочет изменить какие-то требования более низкого приоритета, то фирма сможет пойти на это без дополнительных бюрократических ограничений. В ходе работы по проекту команда не будет прикладывать усилия к требованиям внизу списка, пока не подойдет их очередь. При замене нетронутых требований никакая работа не окажется потерянной, а значит, клиент не потратит деньги на работу, ставшую ненужной.
В качестве заключительного аргумента фирма-претендент может объяснить, что многие ее клиенты получили всю изначально ожидаемую бизнес-ценность задолго до реализации всех требований. Следуя правилу 80/20, они получили 80 % выгод проекта от всего лишь 20 % функциональности. Требования с самым низким приоритетом часто оказываются лишними. Фирма предоставит заказчику возможность отказаться от дальнейшей работы раньше даты окончания контракта, если он считает, что получено достаточно пользы для бизнеса. Разумеется, придется выплатить неустойку, но это будет дешевле, чем реализация и внедрение ненужных требований.
Чтобы выиграть в конкурсе и получить контракт с фиксированными датой и ценой, применяющая скрам фирма может использовать все перечисленные конкурентные преимущества, если потенциальный клиент открыт к обсуждению. Некоторые клиенты будут заинтригованы. Другим не понравится такой подход. Третьи не будут знать, как его обсуждать. На семинаре министерства обороны США в 2002 году я был участником дискуссии об этом подходе. В конце обсуждения специалист ВВС США по контрактам сказал: «Я даже не знаю, о чем вы, коллеги, говорили. Если бы вы предоставили мне материалы, поясняющие это, я отклонил бы вашу заявку по причине несоответствия критериям. Специалисты по контрактам ВВС и других ведомств проходят формальную, строгую подготовку, и ничто из изучаемых тем даже не намекает на то, о чем вы говорили». Претендуя на контракт с фиксированными датой и ценой, вы можете использовать скрам для получения дополнительных преимуществ, но только если ваша аудитория знает, как слушать, и хочет слушать.
Приложение Д
Модель зрелости возможностей создания ПО (CMMI)
CMMI–Capability Maturity Model Integration, набор моделей зрелости возможностей создания ПО, или «моделей полноты потенциала», – это набор моделей эволюционного развития способностей компании разрабатывать программное обеспечение.
В 1986 году Билл Кертис и Марк Полк из Института программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона[25] начали всесторонний обзор зрелости процессов разработки программного обеспечения, чтобы впоследствии улучшать их, и в 1991 году впервые опубликовали CMM, которая, постоянно дорабатываясь, в 2009 году была переименована в CMMI.
CMMI состоит из пяти уровней с номерами от одного до пяти. Первый уровень означает, что организация не имеет определенного, повторяемого или улучшаемого подхода к созданию программного обеспечения. Фактически разработчики самостоятельно прокладывают свой путь к решению. На пятом уровне организация имеет определенный, повторяемый и улучшаемый набор методов для разработки программного обеспечения. Организация первого уровня считается незрелой, организация пятого уровня – зрелой. На каждом уровне методы, которые следует использовать, определяются как ключевые процессные области (КПО). Если организация считает, что полностью реализовала КПО на определенном уровне, она может привлечь оценщика. Если организация соответствует требованиям, ее сертифицируют. Сертификация – большое дело, потому что некоторые компании и правительственные агентства не нанимают фирмы, не сертифицированные как минимум на уровне CMMI 3.
Я уже рассказывал о MegaFund в третьей, пятой и девятой главах. Компания потратила три года и более $40 млн на совершенствование своих подходов к разработке программного обеспечения, пока не была сертифицирована на уровне CMM 3. На этом уровне MegaFund не только обладала стандартизированным подходом к управлению совершенно любым проектом разработки программного обеспечения, но также могла формально определять эти методы. В девятой главе мы рассмотрели, как компания MegaFund масштабировала проект, чтобы быстрее реализовать для клиентов возможность управлять счетами с помощью телефона и через интернет.
К сожалению для MegaFund, компания не определила практики, позволяющие в важном проекте c жесткими сроками автоматизировать нечеткие требования к передовым и непроверенным технологиям, как это описано в восьмой главе. Когда MegaFund начала использовать скрам в этом проекте, он буксовал уже более девяти месяцев, а участники команды безуспешно пытались преодолеть процессуальные и бюрократические препоны, которые CMM третьего уровня наложил на деятельность в неопределенных и непредвиденных обстоятельствах. Я получил неблагоприятное впечатление от CMM в этом проекте и других компаниях. Однако меня все чаще спрашивали, что я думал о CMM и как эта модель связана со скрамом. Поняв, что мне нужны дополнительные информация и знания, я организовал встречу с Марком Полком в Институте программной инженерии осенью 2002 года.
О скраме Марк только слышал, зато был знаком с экстремальным программированием – еще одним аджайловым процессом, подобным скраму, но сконцентрированным больше на инженерии ПО, чем на управлении. В течение первого дня Марк учил меня CMM, а я учил его скраму. Признаюсь, я был очень удивлен и впечатлен CMM. Марк отметил, что это всего лишь фреймворк, описывающий зрелость компании по разработке программного обеспечения. Каким образом добиваться соответствия критериям уровней зрелости – выбор самой организации. Оценщики CMM должны были определить, адекватен ли способ удовлетворения критериев. И тут меня озарило: до 2001 года почти каждая компания использовала предопределенные процессы разработки ПО, поэтому естественно, что фреймворк CMM содержал жесткие предписывающие методы. У них были те же слабые стороны, что и у всех предопределенных подходов, – они работают только в ситуациях, предусмотренных их создателями. Поскольку разработка программного обеспечения является очень комплексным процессом, нашлось очень немного реальных проектов, к которым эти подходы были бы применимы.
Затем Марк перешел к ключевым процессным областям (КПО) разных уровней. Мы оценили, к каким уровням и областям относится скрам. Марк был приятно удивлен: несмотря на то что скрам основан не на предопределенном, а на эмпирическом процессе, использующая его организация будет удовлетворять всем КПО второго уровня и многим КПО третьего уровня, за исключением тех, которые касались стандартизации подходов. Эти КПО были удовлетворены в 2003 году, когда фреймворк скрам, программа обучения Certified Scrum Program и процедура запуска скрам-проекта Project Quickstart были предложены в виде продуктов. На рис. 1 показаны степени от нулевой до второй, в которых скрам соответствует различным КПО второго и третьего уровней. Двойная галочка означает полное соответствие, а одна галочка – в большей части соответствие.
Для демонстрации того, как практики скрама реализуют одну из КПО, давайте взглянем на КПО второго уровня «Управление требованиями». Определение этой КПО: «Цель управления требованиями – добиться единого понимания требований клиента и проектом разработки программного обеспечения и самим клиентом». Скрам удовлетворяет этой КПО с помощью механизма, называемого бэклогом продукта, – открытого, прозрачного и доступного для всех списка поддерживаемых клиентами функциональных и нефункциональных требований, которые используются для управления разработкой спринт за спринтом. Эмергентный характер бэклога продукта позволяет сфокусироваться на элементах с наивысшим порядком. Это позволяет максимизировать вероятность того, что время и силы, инвестированные в детализацию требований, принесут ценность. Менее приоритетные элементы бэклога продукта могут навсегда остаться нереализованными и поэтому игнорируются до тех пор, пока не достигнут вершины списка бэклога продукта.
Эта КПО часто интерпретируется как необходимость поддерживать трассировку требований, чтобы иметь возможность показать, как эти требования реализуются в поставляемой системе. Скрам достигает этой цели путем демонстрации в конце каждого спринта (длительность спринта не более одного месяца). В ходе демонстрации, являющейся частью обзора спринта, клиенты могут увидеть, в какую рабочую бизнес-функцию был превращен каждый взятый в спринт элемент бэклога продукта. С каждой принятой клиентом завершенной функцией бэклог продукта уменьшается на соответствующий ей элемент.
Такой эмпирический подход к трассировке пользовательских требований полностью соответствует критериям КПО, он не создает дополнительную нагрузку на процесс разработки или детальность документации. Он также обеспечивает полную гибкость в управлении и отслеживании изменений требований в любое время на протяжении всего проекта. Остальным процессным областям второго и третьего уровней скрам удовлетворяет аналогичным образом: эмпирически, с минимальной документацией и минимальными дополнительными усилиями.
Переводчик Дмитрий Блинов, консультант по аджайл-трансформациям, скрам-мастер, тренер по личной эффективности и коммуникациям, сертифицированный персональный коуч, фасилитатор. PSM, CLP, KMP, PSPO. Сайт dblinov.com.
Научный редактор Илья Павличенко, скрам-мастер, коуч ACC. Первый в России сертифицированный скрам-тренер от Scrum.org и первый в мире русскоязычный LeSS-тренер. Сайт agilix.ru.
Читать бесплатно другие книги:
