скрам

Работа над задачами в скраме

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

Бэклоги продукта и спринта

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

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

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

Степень детализации требований в бэклоге разная: от подробно проработанных задач на следующий спринт до задач без описания на год вперед. Деятельность по уточнению и оцениванию задач называется product backlog refinement (PBR). Она может проходить в формате регулярной встречи владельца продукта, команды и заказчиков.

Критерии готовности к разработке (DoR)

Зрелая команда берет в спринт только проработанные задачи. Команда сама вырабатывает критерии готовности к разработке (definition of ready, DoR) с учетом особенностей проекта и предметной области. Пример:

Если на проработке задачи «сэкономили», то на выяснение требований, согласования и переделки потеряется больше времени. Скрам-мастер объясняет постановщикам задач, что критерии готовности — это не капризы разработчиков. Пример:

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

Зачем оценивать задачи?

Для быстрой обратной связи владельцу продукта и заказчику о сложности задач. У нас в CityAds был образцовый иллюстрирующий случай.

Оценка задач в часах

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

Оценка задач в стори-поинтах

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

Объем работ больше, если в задаче надо сделать пять экранов, а не два.

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

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

Стори-поинты нужны, чтобы сравнивать задачи друг с другом, поэтому абсолютное значение стори-поинта не важно. Для начала использования сопоставьте 1 стори-поинт несложной типовой задаче. Затем группируете выполненные задачи по условной шкале: чем правее задача, тем сложнее.

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

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

Важно ограничить возможные значения стори-поинтов. Обычно используют числа Фибоначчи (слегка измененные: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100) или степени двойки: чем больше соседние числа, тем больше интервал между ними. Иногда числа вообще заменяют на обозначения размеров одежды: S, M, L, XL, XXL.

Мы пользуемся картами для покера планирования. После обсуждения задачи команда разработки кидает и вскрывает карты.

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

Бывают менее однозначные ситуации.

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

Как оценивать задачи и планировать спринт?

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

Фокус-фактор — это доля времени, которая уходит на разработку запланированных задач, от общего рабочего времени. Например, фокус-фактор 0,5 означает примерно одинаковую долю условной разработки и поддержки. Хорошим считается значение 0,7.

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

Планировать спринт в стори-поинтах помогает понятие производительности команды (velocity). Это сумма оценок в стори-поинтах выполненных в спринте задач. Если команда не успела в течение спринта полностью выполнить задачу, стори-поинты задачи потеряны.

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

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

После этого трекер рисовал диаграмму загруженности каждого участника. Мы понимали, как перераспределить работу, и успеем ли всё сделать:

Диаграмма сгорания, впихинг и скрам

На стендапах полезно визуализировать оставшийся объем работ в спринте на диаграмме сгорания («бёрндаун-чарт»). В идеале объем равномерно уменьшается каждый день. На практике, когда команда успевает выполнить все задачи, в конце спринта объем работы уменьшается быстрее, и график получается примерно таким:

Иногда получается, что график на диаграмме сгорания растет:

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

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

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

Введение в скрам

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

Зачем нужен скрам

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

Команда и спринты

Рабочая единица по скраму — скрам-команда. Она состоит из трех частей:

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

В команде разработки у всех одинаковая роль — «разработчик». У каждого разный опыт и уровень экспертизы, и это влияет на конкретный вид выполняемой работы. Но ответственность за результат у команды общая.

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

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

Рабочий процесс по скраму делится на итерации — спринты. Команда разработки создает и в конце спринта поставляет заказчику некоторую завершенную функциональность — инкремент продукта.

Вот обязательные встречи в течение спринта, без которых у вас не будет скрама:

• планирование,
• ежедневный скрам («стендапы»),
• демонстрация новой функциональности заказчикам и пользователям
• ретроспектива.

Планирование

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

Вот что написано о цели в руководстве:

Цель Спринта — это установленный для Спринта ориентир, который достигается посредством выполнения части Бэклога Продукта. Цель Спринта формулируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.

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

Цель связана с наиболее приоритетной задачей, но не тождественна ей. Польза выбора цели в дополнительной синхронизации ожиданий. Например, на планировании выясняется, что команда разработки скорее всего не может «сделать фичу и выложить в бой», потому что другая команда должна доработать АПИ, админы — запустить новый сервис и т. д. Но по-другому сформулированная цель — «сделать фичу и продемонстрировать на тестовом окружении» — достижима, и на текущий спринт устраивает заказчика, который сам хочет всё посмотреть в действии до выкладки.

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

В следующий раз я расскажу о стендапах и о работе с задачами по скраму.