Гибкая организация
Методика ситуационного контекста
The Situation Context Framework (SCF)
Методика ситуационного контекста (Situation Context Framework) или просто SCF показывает, что существует несколько факторов контекста, в котором команда осуществляет свою деятельность, влияющих на то, как команда выбирает свой подход к работе, включая методики и практики.
Факторы организованы в 2 категории:
Факторы организованы в 2 категории:
1
Ключевые контекстные факторы, влияющие на выбор фундаментального подхода к организации труда в команде — производственного жизненного цикла. Это стратегия поведения команды.
2
Факторы побуждающие команду выбрать ту или иную активность, практику или подход для оптимального решения проблемы с учётом условий, в которых работает команда. Это тактика поведения команды. Disciplined Agile (далее по тексту ДА) называет их тактическими коэффициентами масштабирования.
Ключевые контекстные факторы
- Навыки командыЧлены команды должны обладать навыками или получить навыки, соответствующие той роли, которую они играют в этой конкретной команде.
Например, разработчикам в гибкой команде разработки ПО могут потребоваться:
- навыки "разработки через тестирование" (TDD),
- навыки командной работы и эффективной коммуникации,
- навыки непрерывной интеграции (CI),
- навыки коллективного планирования,
- и так далее.
- Культура командыКоллеги, по своей природе более ориентированные на сотрудничество и командную работу, открытые и пластичные в своей работе, готовые постоянно учится и изменять свои практики и инструменты лучше подходят для гибкой или бережливой разработки, тогда как сотрудники, которым нравится работать в одиночку с привычными инструментами, лучше подходят для традиционных подходов.
- Организационная культураКультура организации может отличаться от культуры команды, что особенно сильно влияет, когда вы только начинаете изучать новые подходы к работе. Пластичная, податливая организация, ориентированная на сотрудничество и участие, быстрее и безболезненнее приспособится к гибкому или бережливому производству, тогда как более жёсткая культура командования и контроля затруднит такой переход.
- Характер проблемыИногда хочется верить, что определённые типы проблем могут быть решены только одним-единственным способом, особенно если он уже известен, но на практике это не так. Например, можно применять гибкий или традиционный подход к проектам по созданию хранилищ данных, к маркетинговым проектам и даже к проектам по закупке услуг и оборудования у подрядчика.
Опыт команды, создавшей Disciplined Agile, показывает, что настоящий вопрос заключается в том, насколько декомпозируемым является потенциальное решение. Например, при желании можно разбить хранилище данных на множество небольших релизов. То же самое можно сказать о разработке и проведении маркетинговой кампании. Но разобрать ракету на несколько отдельно работающих релизов не так-то просто. Либо ракета готова, либо нет. Да, всё ещё возможно применять гибкие методы к разработке и производству авионики и ракет в частности, но команда разрабатывающая и производящая ракеты никогда не будет такой же гибкой, как команда разработчиков ПО, из-за физических и нормативных ограничений, с которыми она сталкиваются. - Ограничения бизнесаТо, как бизнес ограничивает внутренние инициативы, например: настаивает на определённой (часто строгой) дате поставки, на конкретном подходе к управлению бюджетом (часто фиксированная цена проекта), обеспечивает определённую (часто ограниченную) доступность представителей бизнеса на протяжении проекта, безусловно, имеет значение и влияет на подход, который вы выстраиваете, и на команду, которую вы собираете. Это влияет даже на инструменты, которые вы выбираете для проекта, особенно для общения и совместной работы онлайн.
Тактические коэффициенты масштабирования
Размер команды
Команды могут иметь размер от двух до двухсот и более человек. Большие команды обычно формируются для решения более сложных проблем и задач, как правило, из более комплексной предметной области или большей технической сложности. Размер команды напрямую влияет на то, как вы организуете работу и координируете активности внутри команды. Например, большая agile-команда из 600 человек будет разделена на подгруппы, и для координации потребуется команда лидеров, или даже несколько команд лидирующих разные аспекты: координацию и слаженность, архитектуру.
Команда из 50 человек также будет разделена на подкоманды, хотя координация, вероятно, будет проще и, возможно, будет осуществляться ежедневными координационными собраниями представителей каждой подкоманды (метод, иногда называемый Scrum of Scrums).
Тривиально просто координировать деятельность команды из 10 человек.
Команда из 50 человек также будет разделена на подкоманды, хотя координация, вероятно, будет проще и, возможно, будет осуществляться ежедневными координационными собраниями представителей каждой подкоманды (метод, иногда называемый Scrum of Scrums).
Тривиально просто координировать деятельность команды из 10 человек.
Географическая распределённость
Члены команды и ключевые заинтересованные стороны могут находиться в одной комнате; могут находиться на одном этаже в одном здании; на нескольких этажах; некоторые могут работать в разных зданиях; некоторые могут работать из дома и некоторые даже могут работать из разных стран.
Популярным заблуждением является то, что agile-команды должны располагаться в одном месте. Конечно, это очень хорошая идея — заставить людей работать как можно теснее, но организовать это получается не так часто, как хотелось бы. На начальном этапе работы команды требуются большие инвестиции времени в первичное моделирование и планирование коммуникации, чтобы снизить риски связанные с некорректным и несвоевременным распространением информации.
Для увеличения шансов на успех, в ключевые моменты проекта потребуется собирать команду и заинтересованные стороны офлайн, чего многие организации не стремятся делать, потому что транспортные расходы измеряются элементарно, а преимущества личного живого сотрудничества трудно оценить количественно в моменте.
Популярным заблуждением является то, что agile-команды должны располагаться в одном месте. Конечно, это очень хорошая идея — заставить людей работать как можно теснее, но организовать это получается не так часто, как хотелось бы. На начальном этапе работы команды требуются большие инвестиции времени в первичное моделирование и планирование коммуникации, чтобы снизить риски связанные с некорректным и несвоевременным распространением информации.
Для увеличения шансов на успех, в ключевые моменты проекта потребуется собирать команду и заинтересованные стороны офлайн, чего многие организации не стремятся делать, потому что транспортные расходы измеряются элементарно, а преимущества личного живого сотрудничества трудно оценить количественно в моменте.
Организационная распределённость
Имеется в виду необходимость вовлечения в проект сотрудников из нескольких отделов или организаций. Проще всего, если вы оказались в команде, все члены которой из одного отдела или подразделения внутри одной организации, например, в начинающей компании или команде по разработке нового продукта внутри предприятия. Немного сложнее, когда участвуют люди из нескольких отделов или департаментов. Наём подрядчиков для работы под вашим руководством ещё больше усложняет ситуацию. Аутсорсинг части работы внешнему поставщику делает ситуацию ещё сложнее. Партнёрство с несколькими поставщиками ещё сложнее. Аутсорсинг блока работ одному или нескольким поставщикам услуг с совершенно другой культурой, чем ваша, ещё сложнее.
Организационно-распределённые проекты, как правило, сталкиваются с проблемами, связанными с большИми и географически распределёнными командами. Когда задействован аутсорсинг, команды берут на себя риски, связанные с закупками, а после заключения договора и риски управления и координации внешних команд.
Организационно-распределённые проекты, как правило, сталкиваются с проблемами, связанными с большИми и географически распределёнными командами. Когда задействован аутсорсинг, команды берут на себя риски, связанные с закупками, а после заключения договора и риски управления и координации внешних команд.
Доступность навыков
Команде нужны правильные сотрудники с нужными навыками для достижения ожидаемых результатов. В идеальном экстремальном случае у вас есть опытные люди, «сидящие на скамейке запасных», ожидающие начала работы, в иной ситуации вам может потребоваться много месяцев и, возможно, много денег, для создания команды, которая отвечает требованиям к навыкам, чтобы реализовать задуманную инициативу.
Наличие квалифицированных специалистов или, по крайней мере, сотрудников, способных быстро приобрести необходимые навыки, является основой для принятия решения о необходимости организационного распределения. Если ваша организация не имеет лёгкого доступа к необходимым навыкам, или специфические навыки нужны на очень ограниченное время, чтобы получить их, вам может потребоваться заключить партнёрство, привлечь вешнего вендора-консультанта или даже решить передать весь пласт работ внешней организации.
Наличие квалифицированных специалистов или, по крайней мере, сотрудников, способных быстро приобрести необходимые навыки, является основой для принятия решения о необходимости организационного распределения. Если ваша организация не имеет лёгкого доступа к необходимым навыкам, или специфические навыки нужны на очень ограниченное время, чтобы получить их, вам может потребоваться заключить партнёрство, привлечь вешнего вендора-консультанта или даже решить передать весь пласт работ внешней организации.
Регулируемость (Compliance)
Существуют два типа комплаенса. Как правило, более простая форма является добровольной, например, организация хочет соответствовать определённому уровню CMMI или ITIL.
Вторая, и более сложная, форма — нормативная. Команде может потребоваться удовлетворять требованиям регуляторов финансовой, банковской или брокерской деятельности, соблюдать правила конфиденциальности или даже нормативам обеспечения безопасности жизни и здоровья.
Разные регулирования имеют разные требования. С точки зрения процесса разработки комплаенс может требовать: отдельного, часто заблаговременного анализа или исследования, осуществляемого сотрудниками конкретной специализации; дополнительной документации (надеемся, что легковесной); регулярных или запланированных обзоров и проверок; а иногда работы в строго задокументированном процессе, с постоянным или регулярным надзором регуляторного органа.
Вторая, и более сложная, форма — нормативная. Команде может потребоваться удовлетворять требованиям регуляторов финансовой, банковской или брокерской деятельности, соблюдать правила конфиденциальности или даже нормативам обеспечения безопасности жизни и здоровья.
Разные регулирования имеют разные требования. С точки зрения процесса разработки комплаенс может требовать: отдельного, часто заблаговременного анализа или исследования, осуществляемого сотрудниками конкретной специализации; дополнительной документации (надеемся, что легковесной); регулярных или запланированных обзоров и проверок; а иногда работы в строго задокументированном процессе, с постоянным или регулярным надзором регуляторного органа.
Сложность предметной области
… или сложность пространства проблемы (problem space)
Информационный веб-сайт, такой как этот, довольно прост. Сайт электронной коммерции чуть сложнее. Система управления воздушным движением или система жизнеобеспечения крайне сложны.
Чем выше сложность предметной области, в которой работает команда,
Чем выше сложность предметной области, в которой работает команда,
- тем больше времени и усилий требуется тратить на предварительное моделирование и планирование;
- тем вероятнее, что придётся заранее подумать над архитектурой решения и проработать более изощрённую стратегию тестирования;
- тем вероятнее, что понадобятся узкоспециализированные сотрудники для закрытия части работ;
- тем больше нагрузка на владельца продукта (или аналогичную роль, выполняющую бизнес-анализ), требуя более сложных навыков моделирования продукта, систем и субсистем. Возможно, потребуется поддержка специализированных бизнес-аналитиков, системных аналитиков и инженеров.
Комплексность продукта
В простом случае команда столкнётся с разработкой совершенно новых самостоятельных решений, созданных с использованием новых технологий.
Ситуация усложняется, если потребуется переиспользовать существующие активы организации, включая: уже работающее ПО (коробочное или разработанное своими силами); существующие источники данных и сервисы; существующие наборы данных, со всеми их недостатками и так далее. Всё становится ещё сложнее, если требуется поддерживать несколько технологических платформ. Ещё сложнее, если вам нужно реорганизовать (модифицировать или заменить) существующую инфраструктуру, включая устаревшие системы, источники данных и сами данные.
Как и в случае со сложностью предметной области, чем выше сложность решения/продукта, тем больше потребность в предварительном моделировании и изощрённом тестировании на протяжении всего жизненного цикла разработки.
Большая техническая сложность ложится бременем на вашего владельца архитектуры (или аналогичную роль, выполняющую анализ, проектирование и поддержку техничкой- и бизнес-архитектур), требуя от него сильных навыков гибкого проектирования гибких архитектур.
Ситуация усложняется, если потребуется переиспользовать существующие активы организации, включая: уже работающее ПО (коробочное или разработанное своими силами); существующие источники данных и сервисы; существующие наборы данных, со всеми их недостатками и так далее. Всё становится ещё сложнее, если требуется поддерживать несколько технологических платформ. Ещё сложнее, если вам нужно реорганизовать (модифицировать или заменить) существующую инфраструктуру, включая устаревшие системы, источники данных и сами данные.
Как и в случае со сложностью предметной области, чем выше сложность решения/продукта, тем больше потребность в предварительном моделировании и изощрённом тестировании на протяжении всего жизненного цикла разработки.
Большая техническая сложность ложится бременем на вашего владельца архитектуры (или аналогичную роль, выполняющую анализ, проектирование и поддержку техничкой- и бизнес-архитектур), требуя от него сильных навыков гибкого проектирования гибких архитектур.
Пример применения тактических коэффициентов масштабирования для выявления границ применимости популярного фреймворка разработки Scrum
Данная статья основана на публикациях Татьяны Бальшаковой, Марка Лайнза, Майка Гриффинса, Скота Эмблера, Бъёрна Густафссона, Кёртиса Хиббса и Джеймса Тротта.
Блог Disciplined Agile
Блог Disciplined Agile
