Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход?

19 Июн 2015

CEO консалтинговой компании BA-Squared, LLC Angela Wick размышляет о том, как в крупной организации сосуществуют традиционные и гибкие методологии управления проектами, и как облегчить их взаимодействие.

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

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

  • Команда: «Нам не нужны шаблоны, мы работаем по Agile»
  • Лидер команды: «Нам просто нужно разрешение для отказа от шаблонов для Agile-команд»
  • Руководитель проектного офиса отвечает: «Но нам нужны стандарты и последовательность»
  • Бизнес-аналитики не знают, какую роль они должны играть теперь
  • Часть бизнес-аналитиков начинает проекты по классическим стандартам, а затем переделывают их по форме в пользовательские истории (user stories)
  • Другая часть наоборот, вместе с Agile-командами рисует карты историй (story maps), а затем пытаются встроить их в традиционные шаблоны организации

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

Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход? иллюстрация изоляцияИли эти команды остаются вообще без организационных стандартов, что сильно усложняет им жизнь:

Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход? иллюстрация дождь

Переход к Agile рано или поздно заставляет задуматься над важностью стандартов, шаблонов и процессов. Они всё ещё релевантны? Если мы не пользуемся шаблонами, как мы документируем проект? Нужна ли нам документация? Можно ли пользоваться одними и теми же стандартами и шаблонами для разных проектных подходов?

Многие думают, что слова «Agile» и «стандарты» не должны писаться в одном предложении. Стандарты кажутся чем-то чуждым, противоположным принципам Agile. Однако стоит задуматься над тем, какова цель стандартов и как они стали настолько жёсткими и не подходящими для большинства Agile проектов.

Нам известны основные преимущества стандартов для организаций:

  • Эффективность, устойчивость, качество
  • Самый простой путь к общему пониманию
  • Обмен выученными уроками и лучшими практиками
  • Усиление корпоративной культуры
  • Снижение правовых рисков

Как решить эту задачу? Вывести Agile с изолированного острова? Спрятать их от дождя? Очевидным решением может показаться создать отдельные корпоративные стандарты для Agile, и спрятать Agile-команды под собственный зонтик.

Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход? иллюстрация стандарт для Agile

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

Тут у многих могут возникнуть вопросы, нормально ли это, следовать гибридной методологии? Будет ли это всё ещё Agile? Будет ли польза от не 100% Agile? И что такое 100% Agile? Следование Манифесту (Agile Manifesto – прим. пер.), принципам или методологии? Можно ли одновременно следовать принципам Agile и поддерживать традиционный стандарт управления проектами? Есть ли «золотая середина», где мы сможем использовать лучшее или самое подходящее для нас из нескольких подходов, поддерживая имеющуюся организационную культуру, риски, ценности и темп?

Из всего этого можно вывести один, самый ключевой вопрос: Можно ли разработать единый набор организационных стандартов и шаблонов, подходящий для всех проектов в большой компании, классических и Agile?

Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход? иллюстрация общий стандарт

Автор полагает, что да. И даёт несколько советов, как это сделать:

  • Определите необходимый базис. Разберите свои стандарты, отделяя детали, привязанные к методологиям, фокусируясь на целях и задачах того или иного процесса. Пересмотрите те стандарты и шаблоны, которые используете сейчас, выделяя их основную функцию и ценность. Задайтесь вопросами: Какие риски они снижают? Какие требования закона или компании они удовлетворяют? Рассмотрите корпоративную культуру и основные ценности и как тот или иной процесс их поддерживает?
  • Найдите основные ограничения. У любой компании, вне зависимости от методологии есть ограничения: финансовые, политические, культурные, физические, установленные законодательно. Задайтесь вопросами: каковы они? Реальные или гипотетические? Временные или долгосрочные? Для пересмотра и разработки стандарта используйте только реальные и долгосрочные ограничения.
  • Продолжайте отделять. Избавляйтесь от элементов стандартов, которые предписывают создавать конечные результаты, созданные при помощи определённого инструмента или формата. С такой же позиции посмотрите на управление сроками и точки принятия решений при переходе с этапа на этап проекта (stage gates). Обычно точки принятия решений требуют определённого документа и, иногда, определённого времени завершения. Но на самом деле, основная ценность точек принятия решений в понимании этапов и принятии определённых решений. Нужно избавиться от условностей, но сохранить суть процессов. Сохраните только то, что нужно для принятия качественного решения.
  • Пересмотрите требования. Сфокусируйтесь на качестве, ценности и цели. Любые требования, правильно разложенные, организованные и сформулированные подойдут к любой методологии или стандарту. Стандарты не должны устанавливать, как и когда требования пишутся. Вместо этого, стандарт должен фокусироваться на пользователях, их целях, декомпозиции требований и деталях. Требования в каскадных и гибких методологиях выглядят такими разными, но в основе своей они одинаковы, вне зависимости от подхода. Команды способны предоставлять требования в разных форматах, разных уровнях детализации и в разное время. Чем более сложные проекты реализуются – тем более гибким должны быть процессы и стандарты выработки требований.
  • Дифференцируйте инструменты и методы. Не ограничивайте себя в инструментах и методах. Не стоит отказываться от инструмента, просто потому, что он часть другой методологии. Будьте открыты к использованию и адаптации методов из других стандартов и методик. Карты историй и пользовательские истории используются в Agile, но могут быть полезны и в каскадных методологиях, а процессное моделирование подойдёт для обоих подходов. Отличаются только формат и сроки. Множество традиционных методик бизнес-анализа востребованы и в Agile. Сроки, детали и процесс реализации выглядит по-другому, но техника и концепция абсолютно та же.

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

Оригинал: http://www.batimes.com/angela-wick/can-you-develop-standards-that-embrace-both-agile-and-traditional-approaches.html

Смотрите также:


Замечания

  1. Sergey Shadrin - Говорит: Июнь 25, 2015 at 1:15 дп

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

  2. Статья немного про другое все таки, про то, как скрестить традиционную модель УП и Agile-подходы, которые набирают популярность. По жизненному опыту — согласен…

  3. George - Говорит: Июль 22, 2015 at 4:10 пп

    Обратите внимание на RIM-III (российская инструментальная модель) — использование только работающих в конкретных условиях и в конкретном проекте инструментов и методик.

    • Использование только работающих в конкретных условиях и в конкретном проекте инструментов и методик относится к здравому смыслу, любые методики можно применять только к месту…

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Rambler's Top100 Яндекс.Метрика Рейтинг@Mail.ru