Можно ли разработать стандарт, охватывающий и 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-команды под собственный зонтик.
Но зачем создавать, управлять, внедрять и отслеживать работу двух абсолютно разных наборов стандартов и требований, особенно учитывая, что вряд ли сегодня найдётся хоть один проект, 100% соответствующий какой-то одной методологии. На самом деле, большинство корпоративных методологий – гибриды из наиболее подходящих или удобных для компании частей различных стандартов и подходов.
Тут у многих могут возникнуть вопросы, нормально ли это, следовать гибридной методологии? Будет ли это всё ещё Agile? Будет ли польза от не 100% Agile? И что такое 100% Agile? Следование Манифесту (Agile Manifesto – прим. пер.), принципам или методологии? Можно ли одновременно следовать принципам Agile и поддерживать традиционный стандарт управления проектами? Есть ли «золотая середина», где мы сможем использовать лучшее или самое подходящее для нас из нескольких подходов, поддерживая имеющуюся организационную культуру, риски, ценности и темп?
Из всего этого можно вывести один, самый ключевой вопрос: Можно ли разработать единый набор организационных стандартов и шаблонов, подходящий для всех проектов в большой компании, классических и Agile?
Автор полагает, что да. И даёт несколько советов, как это сделать:
- Определите необходимый базис. Разберите свои стандарты, отделяя детали, привязанные к методологиям, фокусируясь на целях и задачах того или иного процесса. Пересмотрите те стандарты и шаблоны, которые используете сейчас, выделяя их основную функцию и ценность. Задайтесь вопросами: Какие риски они снижают? Какие требования закона или компании они удовлетворяют? Рассмотрите корпоративную культуру и основные ценности и как тот или иной процесс их поддерживает?
- Найдите основные ограничения. У любой компании, вне зависимости от методологии есть ограничения: финансовые, политические, культурные, физические, установленные законодательно. Задайтесь вопросами: каковы они? Реальные или гипотетические? Временные или долгосрочные? Для пересмотра и разработки стандарта используйте только реальные и долгосрочные ограничения.
- Продолжайте отделять. Избавляйтесь от элементов стандартов, которые предписывают создавать конечные результаты, созданные при помощи определённого инструмента или формата. С такой же позиции посмотрите на управление сроками и точки принятия решений при переходе с этапа на этап проекта (stage gates). Обычно точки принятия решений требуют определённого документа и, иногда, определённого времени завершения. Но на самом деле, основная ценность точек принятия решений в понимании этапов и принятии определённых решений. Нужно избавиться от условностей, но сохранить суть процессов. Сохраните только то, что нужно для принятия качественного решения.
- Пересмотрите требования. Сфокусируйтесь на качестве, ценности и цели. Любые требования, правильно разложенные, организованные и сформулированные подойдут к любой методологии или стандарту. Стандарты не должны устанавливать, как и когда требования пишутся. Вместо этого, стандарт должен фокусироваться на пользователях, их целях, декомпозиции требований и деталях. Требования в каскадных и гибких методологиях выглядят такими разными, но в основе своей они одинаковы, вне зависимости от подхода. Команды способны предоставлять требования в разных форматах, разных уровнях детализации и в разное время. Чем более сложные проекты реализуются – тем более гибким должны быть процессы и стандарты выработки требований.
- Дифференцируйте инструменты и методы. Не ограничивайте себя в инструментах и методах. Не стоит отказываться от инструмента, просто потому, что он часть другой методологии. Будьте открыты к использованию и адаптации методов из других стандартов и методик. Карты историй и пользовательские истории используются в Agile, но могут быть полезны и в каскадных методологиях, а процессное моделирование подойдёт для обоих подходов. Отличаются только формат и сроки. Множество традиционных методик бизнес-анализа востребованы и в Agile. Сроки, детали и процесс реализации выглядит по-другому, но техника и концепция абсолютно та же.
Автор отмечает, что в своей компании они используют одни и те же инструменты и методики как для традиционных каскадных проектов, так и для Agile-проектов, просто в разные сроки и с разным уровнем детализации. Пусть Agile проекты формулируют требования в форме стикеров, досок или библиотек пользовательских историй в SharePoint, действительно ли им необходимы шаблоны и стандарты, отличные от традиционных? Подходы выглядят очень разными, но в своей основе они одинаковы.
Смотрите также:
- Блог: Программное обеспечение для управление проектами по agile
- Блог: Управление ИТ-проектами, что придёт на смену текущему подходу?
- Консалтинг: методология управления проектами