Часто задаваемые вопросы

Не являются ли бэклог и доски задач простой разновидностью графика проекта? Не делают ли scrum-команды то же самое, что и моя команда?

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

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

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

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

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

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

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

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

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

Разве не более эффективно спланировать все наперед, а позже при необходимости просто уточнить план?

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

Одна из важных причин провала многих крупных проектов – в чересчур подробном изначальном планировании, подробности которого далеки от реальности, потому что у разработчиков просто недостаточно информации. Это приводит к знакомому нам по предыдущим главам CYA-циклу, когда руководители проектов винят разработчиков в неточной оценке объемов работ, а программисты менеджеров – в плохом планировании. Люди обвиняют друг друга, но положение дел не меняется. Страдает только качество программного обеспечения.

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

Разве не является нереальным обещание, что в конце каждого спринта вы будете иметь работающее программное обеспечение, пригодное для демонстрации? Как быть, если команда работает над тем, что нельзя показать наглядно?

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

Любое изменение программного обеспечения можно продемонстрировать, и для программистов крайне полезно найти способ сделать это. Скажем, спринт был направлен на внесение изменений в базу данных. Разработчики не могут просто зайти в нее, внести изменения, а затем двигаться дальше, не проверив, работают ли они, – никто так не делает! Поэтому они написали код, сделали вставки, обновления, изменения, удаления и прочее, чтобы убедиться: изменения базы данных работают корректно. И вероятно, они также внесли изменения в другие части кода, которые используют эту базу.

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

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

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

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

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

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

Эффективная scrum-команда в этом отношении гораздо лучше, чем команда, придерживающаяся административно-командного стиля с «большими требованиями в начале проекта» (BRUF). Причина в том, что scrum-команды встречаются каждый день, чтобы оценить изменения и адаптировать к ним план работы. Эта команда может справиться и с проблемой изменения сроков, и с любым другим возникшим вопросом. Если это одна из тех экстремальных ситуаций, когда нет возможности дождаться следующего спринта, и владелец продукта согласился с этим от имени компании, то команда добавит эту срочную задачу в бэклог спринта, определит ее приоритет (скорее всего, установив его максимальным) и использует свои инструменты планирования – ежедневный scrum-митинг, доску задач, диаграмму сгорания, пользовательские истории, очки историй и скорость, – чтобы держать всех в курсе выполнения задачи и убедиться, что она будет сделана.

Основная разница заключается в том, что Scrum требует от нас быть честными перед самими собой и пользователями в оценке влияния этих изменений на проект. Мы не можем делать вид, что добавление такой работы происходит без затрат. Появится подъем в диаграмме сгорания, и станет очевидно: нужно принять меры для успешного завершения спринта. Впрочем, поскольку scrum-команды обычно выполняют свои обязательства по поставке ценного программного обеспечения, пользователи склонны доверять им. А раз команда демонстрирует работающее ПО, клиенты гораздо лучше понимают, как построена программа и что команда способна сделать за спринт.

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

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

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

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

Это также объясняет, почему многие компании предпочитают менее эффективный водопадный процесс «с большими требованиями в начале». Они готовы вложить больше времени, усилий и денег в создание этих документов, лишь бы снизить количество времени, которое их продавцы и руководители проведут в общении с командами. Ежедневная работа с командой – это очень трудоемкое занятие, руководителю гораздо проще прочитать документ, внести поправки, а затем смириться с не совсем удачным программным обеспечением. И компании часто пытаются исправить ситуацию, добавляя бизнес-аналитиков (улучшая тем самым качество документации), а также дополнительных инженеров по качеству и тестировщиков (чтобы убедиться, что требования были выполнены). Такой подход увеличивает количество дополнительной работы, компенсирующей нежелание исполнительных директоров утруждать себя. Но таков стиль работы во многих компаниях, и он все-таки позволяет создать хорошее программное обеспечение (правда, рано или поздно такие компании все равно окажутся в ситуации, характерной для отчетов CHAOS, и риск создания ими ненужных продуктов резко возрастет).

Если компания ценит программное обеспечение и время создающей его команды гораздо меньше, чем усилия бизнес-подразделений и продавцов, то несложно сделать анализ затрат и выгод – и тогда BRUF оказывается логичным способом построения программного обеспечения. Если вы работаете в компании именно такого типа, то успешная попытка использования Scrum поможет вашим менеджерам и остальным сотрудникам понять ценности Scrum и Agile. Но если это не сработает, вы, по крайней мере, сможете попрактиковаться в Scrum и пополнить свой послужной список неплохими (хотя и не выдающимися) результатами.

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

Есть много различных способов оценки задач. Наиболее популярный из числа используемых scrum-командами – это покерное планирование, одна из общепринятых практик Scrum (GASPs)[46]. Такое планирование изобрел Джеймс Греннинг, соавтор Agile-манифеста. Метод стал популярным благодаря книге Майка Кона Agile Estimating and Planning. Вот как он работает.

В начале покерного планирования все оценщики получают по колоде карт. На каждой карточке написана одна из допустимых оценок. Оценщикам может быть, например, дана колода карт, которая включает 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Карты должны быть подготовлены до проведения собрания по планированию, и цифры следует написать достаточно крупно, чтобы можно было видеть их на расстоянии. Карты можно использовать для повторных сессий покерного планирования.

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

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

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Часто задаваемые вопросы:

  1. Часто задаваемые вопросы
  2. Часто задаваемые вопросы
  3. Часто задаваемые вопросы
  4. Часто задаваемые вопросы
  5. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  6. Часто задаваемые вопросы
  7. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  8. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  9. Часто задаваемые вопросы
  10. Часто задаваемые вопросы
  11. Часто задаваемые вопросы
  12. Часто задаваемые вопросы
  13. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  14. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ