English Version

Приритезация бэклога для практиков: три важных аспекта

Автор: Александр Якима

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

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

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

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

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

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

Открытый Воркшоп: Приоритезация Бэклога

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

Этот воркшоп будет полезен Менеджерам Продукта, Бизнес-Аналитикам, Проектным Менеджерам и Лидерам Команд, а также всем, кому интересно ознакомиться с подходами определения важности бизнес-задач в контексте разработки продукта.

Дата и время: 22 декабря, 2011, 18:00. Продолжительность: 2 часа.

Место проведения: Учебный Центр компании "Люксофт" по г. Киев, ул. Радищева 10/14, корпус Б, офисный центр "Ирва".

Воркшоп проведут Александр Якима и Филипп Дзюба.

Ивент бесплатный, но необходима регистрация.

РЕГИСТРАЦИЯ ЗАКРЫТА!

Бизнес-Аналитик в Agile

Автор: Александр Якима.

Какова роль бизнес-аналитика в Agile? Вот наш центральный вопрос, на который мы постараемся ответить без излишнего сравнительного драматизма с другими методологиями. Просто и по сути.

Среди всех аспектов, наиболее существенны следующие:

- Бизнес-аналитик в Agile – это центральная роль в области, которая в Agile является достоянием всех участников процесса, в частности, команды и заказчика. Речь идет об управлении требованиями. Вся команда участвует в PBR (Product Backlog Refinement), в планировании итерации, в различного рода воркшопах. Также и заказчик соприкасается с командой в разрезе требований часто на том же PBR, планировании, демо. Таким образом, Agile бизнес-аналитик всегда заинтересован, чтобы команда и заказчик максимально понимали и применяли методы эффективной работы с требованиями, в то время как он, скорее, оркестрирует и корректирует процесс.

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

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

а)Четкая дисциплина коротких итераций – чтобы быстро и часто верифицировать и валидироать требования. Agile бизнес-аналитик больше всего верит только одному источнику истины: рабочему ПО. Вместо длительных рассуждений и предположений – прототип , вместо формального анализа рисков – функциональный спайк – вот эффективный подход Agile БА.

б) Групповая работа (см., например: Define-Build-Test ) над пользовательскими историями (или как бы не назывались «кванты» требований, которыми команда превращает идею в рабочую функциональность) – чтобы с одной стороны всегда было несколько пар глаз в одном и том же контексте, а с другой – меньше работы в прогрессе , которая приводит только к тому, что требования имплементируются неполно и некачественно.

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

- БА Очень хорошо и четко понимает принципы Lean и неотъемлемую сложность ПО. Как эти две вещи связаны? Очень просто. Agile бизнес-аналитик не руководствуется наивным оптимизмом по поводу того, что систему можно точно заспецифицировать на целый релиз или даже больше и потом успешно реализовать, как это было задумано. Тут здорово помогает подход «точно вовремя» (Just-in-time или JIT) из Lean, который исходит из «контейнеров» (например, пользовательских историй, ММФ – минимальных маркетируемых фич и т. д.) в качестве единиц требований, которые наполняются по ходу выяснения новых обстоятельств и информации в принципе недоступной на этапе начального специфицирования и планирования разработки. Метод проработки «точно вовремя», вместе с четкой приоритезацией требований, составляют мощные средства для успешной работы с требованиями. Удивительно, но именно этот подход спасает даже в случае, когда заказчик принципиально настроен на fixed scope.

Итоги: Роль бизнес-аналитика в Agile обретает еще большую важность, так как теперь это уже не роль «сама в себе», а активное связующее звено между бизнесом и инжинирингом. Роль бизнес-аналитика, как лидера и фасилитатора, помогает заказчику и команде выработать наиболее подходящие в каждом отдельном контексте методы работы с требованиями. Agile бизнес-аналитик видит гораздо глубже и помогает команде внедрить и поддерживать гибкие инженерные практики, поддерживающие качественную и своевременную имплементацию/валидацию требований. Наконец, принципы Lean и правильное понимание неотъемлемой сложности ПО помогает выбрать оптимальный курс развития релиза продукта.


На правах рекламы: Тренинги для компаний.

"Непотопляемый" приемочный тест

Автор: Александр Якима

На прошлом воркшопе, посвященном Разработке Через Приемочные Тесты (ATDD) (/2011/11/workshop-atdd-with-junit.html) прозвучал вопрос о том, как быть с приемочным тестом, идея которого пришла уже после написания самой функциональности и, более того, мы практически уверены, что тест успешно выполнится. Суть вопроса в том, нужен ли вообще такой тест, который, кстати, даже не удастся "завалить"?

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

Не будем также забывать, что речь идет о приемочных тестах, которые обычно определяются командой совместно с заказчиком (в идеальном случае), или хотя бы командой, но не индивидуально отдельно взятым разработчиком. А это значит, что перед имплементацией у нас уже быдет целый набор "примеров" поведения системы, которые мы и реализуем в качестве тестов вначале, а потом добавим реализацию. Таким образом мы сможем увидеть все тесты незапускающимися в какой-то момент времени.

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

Powered by Blogger