Заказать звонок
Москва, Пресненская набережная, 12
Корзина 0
Войти
PMJournal.ru - управление проектами
Портал для профессионалов в управлении проектами
Услуги
Книги
Онлайн-курсы
Кейсы
Статьи
Новости
Обзоры
Тренинги
Работа
Персоны
Мероприятия
Ещё
    PMJournal.ru - управление проектами
    Услуги
    Книги
    Онлайн-курсы
    Кейсы
    Статьи
    Новости
    Обзоры
    Тренинги
    Работа
    Персоны
    Мероприятия
    Ещё
      0
      PMJournal.ru - управление проектами
      0
      • Услуги
      • Книги
      • Онлайн-курсы
      • Кейсы
      • Статьи
      • Новости
      • Обзоры
      • Тренинги
      • Работа
      • Персоны
      • Мероприятия
      • Личный кабинет
      • Корзина0
      Будьте на связи
      Москва, Пресненская набережная, 12
      info@pmjournal.ru
      • Facebook
      • Вконтакте
      • Twitter
      • Instagram
      • Telegram

      Управление требованиями в Agile. Бизнес-анализ в гибких проектах

      • Главная
      • Блог
      • Бизнес статьи
      • Управление требованиями в Agile. Бизнес-анализ в гибких проектах
      // Бизнес статьи
      Автор: PM Angel

      Управление требованиями в Agile: что это значит? Принципы управления требованиями в Agile. Бизнес-анализ в управлении требованиями


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

      Управление требованиями в Agile: что это значит?

      управление требованиями в Agile

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

      Артефакты в управлении требованиями в Agile:

      • backlog (беклог) – список требований, которым должен соответствовать продукт
      • user story (пользовательская история) – требование, которое написал Product Owner или его представитель
      • task (задача, необязательный элемент) – результат декомпозиции UserStory на более мелкие части.

      Принципы управления требованиями в Agile

      Есть несколько принципов управления требования в Agile:

      1. Разработка от общего к частному (от общего vision к конкретным фичам).
      2. Инкрементальность vs итеративность (каждый этап реализации дает прирост ценности для клиента/заказчика).
      3. Итеративная реализация (реализация/поставка осуществляется короткими итерациями).
      4. Коммуникации лицом к лицу.
      5. Передача бизнес-контекста команде важнее идеально написанных требований.

      Бизнес-анализ в управлении требованиями

      Бизнес-анализ настолько важен в проектах с гибкой разработкой, что мы делаем это каждый день в течение всего цикла разработки, а не только на начальной фазе проекта. Разработка по гибкой модели (Agile Model Driven Development – AMDD) предполагает использование нескольких лучших практик, которые отражают место бизнес анализа в гибких проектах. Это следующие практики:

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

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

      Моделировать немного вперед. Иногда требования, которые по приоритету находятся “недалеко” от самых приоритетных достаточно сложны. Это побуждает вас инвестировать определенные усилия для того, чтобы их исследовать до момента, когда они попадут в разработку. Данное исследование снижает риск при разработке. Подобное явление достаточно редко, но иногда случается.

      Предварительный анализ требований. В начале гибкого проекта вам необходимо потратить часть времени для идентификации границ проекта и для создания начального набора приоритезированных требований. Еще один результат – идентификация всех заинтересованных лиц со стороны заказчика. Данный процесс занимает от нескольких дней до нескольких недель.

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

      Моделирование при помощи штурма (Model storming). На протяжении итерации вы будете регулярно, в одно и то же, время заниматься моделированием системы в течение нескольких минут. ДЛя этого вы будете использовать подход штурма (мозшгового). Тем самым вы будете регулярно исследовать детали требований или архитектуры.

      Разработка через тестирование (Test-driven development – TDD). Напишите тест (или набор тестов – прим. пер.), для требований или архитектуры, а затем просто напишите ровно столько кода, чтобы данный набор тестов выполнялся. TDD – признанный хороший подход к своевременной спецификации требований.

      AMDD (Agile Model Driven Development) предлагает высокоитеративный, очень гибкий и с высокой степенью сотрудничества подход к анализу, который учитывает в то же время риски, неотъемлемо связанные с требованиями. Замечательной стороной agile-философии является то, что запрос на изменение требований на поздних стадиях разработки может быть превращен в конкурентное преимущество продукта, если только вы готовы с ним работать. Гибкие методы работы с требованиями могут сильно отличаться и казаться достаточно некомфортными поначалу для людей, привыкших с традиционным прошлым в разработке ПО.

      Догма документирования

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

      Первое. Агилисты обнаружили, что подход, при котором детальные требования разрабатываются на ранних стадиях проекта, ведет к увеличению проектных рисков и существенных затрат на практике. Существует несколько причин этого. Одна из них – людям (заказчику – прим. пер.) трудно определить то, что им по-настоящему нужно. Еще причины – документация очень плохой способ общения, а также традиционное “избегание изменений” ведет к тому, что заинтересованные лица диктуют фиктивные требования для заполнения документа.

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

      Второе, агилисты понимают, что общение через документацию – худший способ передачи информации между людьми. Об этом также говорит Media Richness Theory (MRT). В свое время мы провели опрос среди различных групп разработчиков внутри нашей компании. Мы попросили их оценить Эффективность различных коммуникационных стратегий. Ниже – результаты этого опроса:

      Таблица-1. Эффективность коммуникационных стратегий в agile-командах

      Коммуникационная стратегия Внутри команды С заказчиком (заинтересованными лицами)
      Лицом к лицу (ЛкЛ) 4.25 4.06
      ЛкЛ у доски 4.24 3.46
      Обзорные диаграммы 2.54 1.89
      Чат онлайн 2.10 0.15
      Обзорная документация 1.84 1.86
      Телеконференции 1.42 1.51
      Видеоконференции 1.34 1.62
      Электронная почта 1.08 1.32
      Детальная документация -0.34 0.16

      Гибкие методы работают лучше

      Мы провели опрос людей, работавших в софтверных проектах с использованием различных методик разработки. Результаты оказались любопытными. В тех командах, кто работал по итеративным методологиям, таким как RUP количество успешных проектов составило 71%. На втором месте оказались команды, исповедовавшие методики Scrum или Экстремального Программирования (Extreme Programming – XP) – 70% успешных проектов. Традиционные команды с водопадными моделями разработки заняли третье место – 66% успешных проектов. И, наконец, команды, работавшие по методам ad-hoc (как придется, по ситуации, по наитию) имели в своем багаже лишь 62% успехов.

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

      Насколько подробной должна быть спецификация?

      Модель зрелости гибких процессов (Agile Process Maturity Model – APMM) дает некоторые рекомендации относительно спецификации требований в гибких процессах.

      Достаточные, но минимальные артефакты (Just barely good enough (JBGE) artifacts). Модель или документ должны быть достаточными для удовлетворения потребностей в конкретной ситуации, но не более того. Этот принцип служит важным фильтром большинства некотролируемой бюрократической детализации. Однако, принцип JBGE зависит от ситуации, и порой трудно определить, какого уровня детализации достаточен для той или иной ситуации.

      Документируйте поздно. Пишите документацию так поздно как возможно. Другими словами ранние инвестиции в документацию скорее всего не оправдаются.

      Выполняемые спецификации. Если требования должны быть тестируемыми, почему бы не выкинуть промежуточное звено документации и не специфицировать требования в виде выполняемых “тестов-историй”? Почему не отобразить детали дизайна (здесь, скорее всего, речь идет об архитектуре – прим. пер.) в виде выполняемых тестов, вместо статической документации?

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

      Размер команды (Team size)

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

      Геораспределенность (Geographical distribution)

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

      Соблюдение установленных нормативов (Regulatory compliance)

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

      Дисциплина (внутренние правила) предприятия (Enterprise discipline)

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

      Организационная некомпактность (Organization distribution)

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

      Сложность системы (Application complexity)

      Некоторые приложения более сложные, чем другие, особенно когда создаваемая система призвана объединять уже существующее ПО, платформы, источники данных. Традиционный подход говорит, что в таком случае необходимо (если таковая документация отсутствует) задокументировать все системы, с которыми предстоит работать будущему продукту. Т.е. создать документацию, отображающую ситуацию “как есть”. Этот подход верен лишь частично. Гораздо лучше будет документировать то “как есть”, используя стратегию “по требованию” и “JBGE” (см. выше).

      Автор: PM Angel
      Понравилось Понравилось Не понравилось Не понравилось

      Теги
      Agile
      Поделиться
      Назад к списку
      • Комментарии
      • Facebook
      • Вконтакте
      Загрузка комментариев...
      Категории
      • Кейсы40
      • Бизнес статьи35
      • Новости13
      • Обзоры38
      • Проект "Бизнес-эволюция"0
      • Тренинги4
      • Работа9
      • Персоны64
      • Мероприятия4
      Это интересно
      • Краткое содержание PMBOK 7
        Краткое содержание PMBOK 7
      • Наш новый проект "FADU.RU - сообщество предпринимателей, бизнес и технологии"
        Наш новый проект "FADU.RU - сообщество предпринимателей, бизнес и технологии"
      • Agile - быть или не быть?
        Agile - быть или не быть?
      • Как ИТ-проекты выглядят со стороны Заказчика?
        Как ИТ-проекты выглядят со стороны Заказчика?
      • Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
        Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      • Проектный офис – баланс человеческих ресурсов и программного обеспечения
        Проектный офис – баланс человеческих ресурсов и программного обеспечения
      • Что влияет на эффективность проектных команд
        Что влияет на эффективность проектных команд
      • Синдром отличника
        Синдром отличника
      • Коммуникации в управлении проектами
        Коммуникации в управлении проектами
      • Отчет об исследовании Agile в России 2018
        Отчет об исследовании Agile в России 2018
      • Об эффекте сотой обезьяны
        Об эффекте сотой обезьяны
      • Дюжина ножей в спину PMO
        Дюжина ножей в спину PMO
      • Книга "Как сдать экзамен PMP (Project Management Professional)"
        Книга "Как сдать экзамен PMP (Project Management Professional)"
      • О нулях и единицах в проектных коммуникациях
        О нулях и единицах в проектных коммуникациях
      • Пишите быстро, отвечайте медленно
        Пишите быстро, отвечайте медленно
      • Управление ожиданиями и ожидание управления
        Управление ожиданиями и ожидание управления
      • Книга "Корпоративная система управления проектами"
        Книга "Корпоративная система управления проектами"
      • Проекты по слиянию и поглощению (\M&A)
        Проекты по слиянию и поглощению (\M&A)
      • Эффективное управление хаосом
        Эффективное управление хаосом
      • Страх потери в проектном управлении
        Страх потери в проектном управлении
      Облако тегов
      50 проектов Agile Gartner IPMA jira Kanban M&A MS Project opm3 PDCA PM PMBOK PMBOK7 PMI PMP PRINCE2 Project Manager RUP Scrum waterfall web-разработка ZohoProjects анти КСУП Боль веб-сервис внедрение информационной системы управления проектами внедрение корпоративной системы управления проектами внедрение проектной методололгии жизненный цикл проекта зачем нужно проектное управление информационная система управления проектами ИСУП коммуникации конференция по управлению проектами Корпоративная Система Управления Проектами КСУП Менеджер проекта Менеджмент менеджмент менеджмент проектов веб-сервисы Методология проектного управления Мотивация области управления проектами Обучение управлению проектами Онлайн-обучение онлайн-тренинги по управлению проектами Онлайн-школа освоенный объем погуби проектное управление подборка принимать решения приоритезация провал проекта продакшн Проектный офис проекты процессное управление процессы управления проектами регулярный менеджмент Роман об управлении проектами Руководитель проекта сервисы сертификация по управлению проектами Стандарт управления проектами ГОСТ строительные проекты тайм-менеджмент технология проектного управления типы коммуникаций типы контрактов Тренинги умение договариваться умение спорить Управление бюджетом управление закупками Управление идеями управление инновациями Управление интеграцией Управление качеством Управление коммуникациями Управление персоналом управление поручениями Управление проектами управление проектами Управление проектами в органах государственной власти Управление проектом управление рисками Управление содержанием Управление сроками Управление стейкхолдерами управление хаосом Фейковое проектное управление финансовый анализ ценность проектного управления Цитаты об управлении проектами Цифровая трансформация
      Подпишитесь на нашу рассылку и получайте первыми все самые интересные новости об управлении проектами!
      Онлайн-школа по управлению проектами
      Авторский тренинг «Стань Руководителем проекта, начни зарабатывать больше»
      Авторский тренинг "Как повысить эффективность бизнеса? Внедряй Корпоративную систему управления проектами!"
      Услуги по управлению проектами
      Внедрение Корпоративной Системы Управления Проектами (КСУП)
      Книги по управлению проектами
      Книга "Корпоративная система управления проектами"
      Книга "Как сдать экзамен PMP (Project Management Professional)"
      Наши контакты


      Заказать звонок
      info@pmjournal.ru
      Москва, Пресненская набережная, 12
      © 2025 PMJournal.ru - управление проектами. Все права защищены.
      • Вконтакте
      • Facebook
      • Twitter
      • Instagram
      • Telegram
      0