… когда каждый просто страстно делает свое дело, то все работает хорошо. Однако по мере роста организации и продукта, растет объем информации, которую командам нужно осваивать, которой нужно управлять и делиться для выполнения своей работы. Решения становятся все более чувствительными к контексту (как на командном команды, так и на продуктовом уровне). По мере взросления организации возрастает комплексность и напрашивается создание структуры. Вы ищете организационную структуру, которая позволит оптимизировать способность команды выполнять задачи для создания Величайшей Ценности.
✥ ✥ ✥
Эффективная коммуникация и обратная связь лежат в основе эффективной комплексной системы разработки, и организационная структура должна быть оптимизирована под наиболее важные линии коммуникации. Общение и регулярная обратная связь, а также самоорганизация лежат в основе адаптивности. Взаимодействие людей с различными, сквозными интересами лежат в основе инноваций.
Команды Разработки, работающие над комплексными продуктами, постоянно борются с двойственной природой формы и содержания. Мы склонны формировать организационные юниты вокруг активностей по разработке. Более того, формат и содержание являются просто социальными конструктами и несколько произвольными категориями: надежность может быть столь же непреодолимым требованием для данной системы, в то время как красота, обратная совместимость или другие проблемы могут преобладать. В каждом случае бизнес выигрывает от того, что Команда Разработки организует себя вокруг наиболее важных бизнес-задач, какими бы они ни были.
Поскольку ваша команда только начинает развиваться и начинает двигаться к созданию Скрам-команды, у вас появляется все больше людей, которые работают как один организационный юнит для выполнения всех функций (планирование релизов, разработка и профессиональный рост). Но рост и зрелость также вызывают дискомфорт, поскольку команды жаждут неструктурированной эффективности, которая была на первых порах существования компании/организации. Тем не менее, чтобы расти и правильно управлять продуктом на рынке, требуется более дисциплинированная организационная структура и легковесное управление.
Культура требует структуры для эффективного функционирования целого. Наиболее эффективное общение всегда происходит локально в рамках привычного, поэтому крайне важно локализовать процесс принятия решений вокруг наиболее важных организационных вопросов. В любой нетривиальной социальной организации важно, чтобы люди могли быстро связать любую интересующую область с наиболее эффективным «местом, куда можно отправиться», когда им нужна информация об этой области или необходимо предпринять действия в этой области.
Простое организационное разделение (то есть иерархия) достаточно в простых доменах, которые имеют дело только с одним набором разделимых задач. Иерархический подход ломается в типичном случае разработки с множеством пересекающихся задач. Это подталкивает к созданию более крупных и более комплексных организационных единиц, которые пытаются решить проблему с экономией на масштабе. Тем не менее, наиболее эффективные рабочие команды — Небольшие Команды, и вам нужно как-то разделить работу между ними.
Однако, ни одна команда не является отдельным островом, а разработка — больше, чем просто совокупность островов. Команды самостоятельно развивают свою идентичность, где естественная ксенофобия (потребности в знакомых лицах) заставляет команды придавать второстепенное значение проблемам, происходящим вне их социального круга. Если вы ограничиваете организацию только одним набором социальных взаимодействий, основанных на одном разделении, вы теряете идеи, питающие инновации.
Скорость принятия решений имеет первостепенное значение. Некоторые вопросы являются неотложными («На нас нападает другое племя, и мы должны защититься от них»), в то время как другие, хотя и важны, терпят или даже требуют более продолжительного обсуждения («Каково лучшее место для нового конференц-зала?»). Термин «разделение слоев» описывает связанные процессы, которые протекают с разными скоростями, после представления о тектонических плитах, которые движутся друг через друга, например, приводят к землетрясению. И архитектура зданий, и область архитектуры программного обеспечения приняли это понятие, чтобы описать структуры или проблемы с различными скоростями изменения в плотно связанной системе. Компания должна структурировать свою организацию, чтобы иметь возможность быстро реагировать на запросы первой категории, не снижая ее эффективность для запросов второй.
Другим Аджайл-принципом является то, что мы обращаемся наружу: то есть мы фокусируемся на конечном пользователе, рынке и клиентах, а не на инструментах и технологиях, которые мы используем для своей работы. Организация должна также адресовать эту проблему, поскольку она является ключом к ценностному предложению и построению всего Потока Создания Ценности разработки.
В конце концов, структура организации должна иметь столько же общего со структурой процесса, как и со структурой продукта.
Поэтому,
Организуйте разработку в Небольших командах (примерно 5 человек), в соответствии с наиболее важными задачами для создания ценности. Дополните эту структуру небольшим количеством сквозных структур для второстепенных, но важных задач, не забывая, что эти структуры являются лишь оптимизацией того, что в противном случае является открытой средой неограниченного сотрудничества.
Рассмотрим организацию, которая создает мобильный телефон. Можно организовать свои Скрам-команды вокруг того, что может быть поставлено на рынок или главной функциональности. Таким образом, может быть одна команда для адресной книги, другая для календаря и другая для более традиционных функций телефона: см. Области Ценностей. Это основные задачи бизнеса. Но могут быть группы, которые собираются вместе, чтобы определить методы, политики и корпоративные стандарты (например, внешний вид пользовательского интерфейса), в состав которых входят представители каждой Скрам-команды. Эти группы не создают продукт, а служат информационным обменом и источниками стандартов, которые определяют развитие. В здоровых организациях существует почти полное совпадение между членством в этих последних группах и членством в Команде Разработки.
В большинстве сред основная организационная структура отражает структуру основных заинтересованных сторон, которой обычно является рынок. По этой причине мы организуем Скрам-команды не вокруг внутренних артефактов, ни в соответствии с доменной экспертизой, а скорее вокруг того, что может быть поставлено на рынок, например, фич.
Организация вокруг фич или того, что может быть поставлено на рынок, также является преимуществом для восприимчивости рынка и сокращения времени выхода на рынок (T2M), так как команда является центром всей работы, необходимой для реализации фичи. Это сохраняет координацию в организационных рамках. Если рабочие подсистемы или основные компетенции определяют организационную структуру, то изменения на рынке или в сущности поставки, вероятно, повлекут за собой координацию между несколькими командами или организациями, что приведет к снижению оперативности и увеличению времени принятия решений.
Если это единственная структура, она поддерживает только взгляд на рынок и маргинализирует множество других важных бизнес-задач. Чтобы эта структура работала, она должна быть дополнена сквозными структурами, которые поддерживают второй уровень эффективности коммуникации, например, связанные с основными компетенциями. Таким образом, этот паттерн почти всегда используется вместе с паттерном Birds of a Feather и паттерном, описанным в разделе Domain Expertise in Roles. Организационная структура рушит стены, которые естественно образуются между командами. Сделайте так, чтобы продуктовые усилия в компании были соединены друг с другом и с исполнительным руководством через MetaScrum. Команды, которые развили Team Pride (чувство гордости), будут более эффективными, поскольку эта или другая эквивалентная сила будет стимулировать ответственность. Это помогает обеспечить работу этих структур, несмотря на ксенофобские эффекты членства в команде.
Свяжите все это вместе с открытой средой без стен и без дверей. Команды разработки — это всего лишь подразделение, занимающееся разработкой, и здесь не должно быть помех, ограничивающих свободное взаимодействие между разработчиками между командами. Добавьте небольшие комнаты поблизости для коротких периодов тишины, серьезных размышлений и небольших встреч.
Любая составляющая ценности может быть использована в качестве критерия организации. Например, Скрам высоко ценит колоцированность членов команды, поэтому базовые границы организации, скорее всего, соответствуют Колоцированным командам.
✥ ✥ ✥
Обратите внимание, что в хорошем Скраме есть два уровня закона Конвея: один основан на фокусе на продукте, а другой — на областях компетенции. На поверхностном уровне мы организуем команду в соответствии с процессом; это является главной задачей как внутренних, так и внешних аспектов процесса. Итак, три сферы владения процессом:
В Скраме Команды Разработки – фиче (продуктовые) команды. То есть основной принцип организации Скрам-команды заключается в том, что она должна соответствовать последовательности поставок фич вдоль всего потока создания ценности. Внутри Скрама существует слабая, поверхностная иерархическая организация, которая объединяет несколько Команд Разработки с общим Владельцем Продукта в организации, называемой Scrum of Scrums. Каждая Команда Разработки в рамках одного продукта разрабатывает один набор фич одновременно. Со временем ключевые бизнес-драйверы, общие бизнес-знания и артефакты Потока создания ценности свяжут эти функции. В Команде Разработки нет признанных титулов или подкоманд.
Существует много путей распределения работы по фиче-командам. Команда Разработки может поставлять функциональность для определенного рынка (смотри Organization Follows Market) или разработать продукт для некоторого подмножества корпоративного технологического спектра (одна команда для телефонов, а другая для планшетов, хотя оба используют большую часть одного и того же программного обеспечения). В общем, каждая команда должна быть сформирована вокруг некоторого продукта, который учитывает компонент ценности организации: смотри Value Stream Fork. Тем не менее, Скрам не одобряет структуру, где каждая Команда Разработки владеет одной частью продукта или только его сборкой. Если члены какой-либо отдельной команды могут разрабатывать только одну часть системы, им необходимо будет координировать множество решений по разработке с другими командами. Командам становится трудно принимать решения локально, а результаты включают задержку обратной связи и передачи.
На втором уровне Закона Конвея Скраме, люди организуются вокруг областей компетенций, в которых навыки повышают ценность. Эти Birds of a Feather помогают участникам углубить свои знания в какой-либо профессиональной или технической области, когда они делятся идеями или проходят обучение. У большинства людей есть врожденное желание совершенствоваться, и эти группы питают индивидуальную гордость, когда члены команды учатся и растут. Но опять же, эти группы неформальны, и любой член команды может принадлежать к нескольким Birds of a Feather, а также к своей собственной Скрам-команде. Смотрите также Domain Expertise in Roles.
Границы и идентичность Команды Разработки, как и Скрам-команды являются явными. Понимание идентичности команды – ключ к Team Pride и эффективной работе организации, поскольку идентичность команды создает социальный контекст, который помогает оптимизировать принятие решений. Любое понятие организационной идентичности, выходящее за рамки этих двух понятий, должно быть негласным, а не явным или контролируемым. Опять же, в Команде Разработки нет официальных титулов, кроме «Разработчик». Если есть только одно неприкосновенное правило, так это то, что ни один человек не может использовать свою негласную позицию для того, чтобы отвергнуть командный консенсус или каким-либо другим образом ослабить дух командной работы, как в «Духе игры». Совместно разработанные Нормы поведения являются сильным предвестником идентичности команды.
В ролях может быть экспертиза на индивидуальном уровне, тогда важно дополнить этот паттерн Cross-Functional Teams везде, где это возможно, чтобы оптимизировать возможности локального принятия решений.
Оригинальный Закон Конвея появился из разработки программного обеспечения. Существует множество мифов, связанных с происхождением и практикой закона Конвея. Долгое время считалось, что объектная ориентация поддерживает закон Конвея, локализуя рыночные интересы внутри классов.
Это полуправда; классы, как правило, инкапсулируют долгосрочные проблемы основных компетенций организации. Тем не менее, объектная ориентация, по-видимому, фокусируется на связи между экспертизой разработчиков и артефактами, которые они разрабатывают, а не на какой-либо связи с рынком или прецедентами использования. Опасения за соответствие рыночной структуре должны превзойти тревогу о мировоззрении разработчиков их процесса и продукта.
Водопадный стиль разработки достиг своего расцвета. В водопадных организациях основная организационная структура состояла из следующих этапов процесса: анализ требований, проектирование, внедрение и тестирование. Согласно закону Конвея, организационная структура отражала эти проблемы процесса.
Программное обеспечение также может очень хорошо отражать эти этапы: например, сервис-ориентированная архитектура (SOA) будет отражать большую часть требований к добавленной стоимости на уровне интеграции служб, в то время как отдельные службы находятся на другом уровне. В то время как подходы к разработке программного обеспечения времен водопада пытались привести рыночные проблемы (варианты использования) в соответствие с архитектурой, организационная структура пересекала эту таксономию. То же самое можно сказать и об организации сборочных линий на фабриках.
Так как Команды Рарзработки – фиче-команды, они должны фокусироваться на одной фиче в один момент времени (как в Swarming). Основным результатом Скрама для рынка является фича, и в этом смысле есть соответствие между структурой команды и рынком. Скрам ничего не говорит об архитектуре продукта, но в духе Аджайла препятствовать индивидуальному владению кодом. Каждая Команда Разработки имеет право работать в любой части продукта. Можно сказать, что Скрам балансирует выгоду организации
Можно сказать что скрам создает баланс между преимуществами инкапсуляции и направленностью команды на рыночный результат. Владелец Продукта, с помощью Команды Разработки, управляет тем, как обрабатывать взаимосвязи функций, возникающих с течением времени.
Рассмотрим, например, что одна команда может реализовать фичу ожидания вызова для телекоммуникационной системы, в то время как другая реализует переадресацию вызовов. Из-за эмерджентности вы не всегда можете предсказать цену разрешения зависимостей между любыми двумя Элементами Бэклога Продукта (PBI), поэтому в целом невозможно преодолеть эту проблему, назначив PBI командам. В любом случае, преждевременное назначение работы командам может сделать невозможной эффективную работу людей над сложными частями (особенно теми, которые связаны с взаимодействием между частями) и ограничить самоорганизацию на уровне Скрам-команды. Эти две фичи могут быть сильно взаимозависимыми, но Скрам структура не дает приоритетный статус этим взаимодействиям. В этом случае, вероятно, было бы лучше, если бы обе фичи разрабатывала одна команда. Распределение работы между командами основывается на постоянном планировании и совместном принятии решений, начиная с Планирования Спринта. Хорошая Скрам-команда стремится разделить работу между Командами Разработки посредством тесного, но ограниченного по времени взаимодействия между Владельцем Продукта и Командами Разработки, например, в случаях постоянной Актуализации Бэклога Продукта, а также на Планировании Спринта.
Обычно менеджмент – компонент организационной структуры, хотя есть некоторые Скрам организации, которые работают без менеджеров (например, смотрите недавнее видео о гибкой трансформации в Bosch Software Innovations. Этос Скрама имеет тенденцию фокусироваться на людях и продукте, и фокус воплощен в ролях Скрама (как Команда Разработки и Команда Владельца Продукта) и организациях, которые они представляют. Если организация с уже существующими менеджерами намеревается внедрить Скрам, для Скрама слишком просто отторгнуть управленческую часть организации как потустороннюю. В таких ситуациях, когда нет возможности создать организация без менеджмента, очень важно Вовлекать Менеджеров.
✥ ✥ ✥
Эффективная коммуникация и обратная связь лежат в основе эффективной комплексной системы разработки, и организационная структура должна быть оптимизирована под наиболее важные линии коммуникации. Общение и регулярная обратная связь, а также самоорганизация лежат в основе адаптивности. Взаимодействие людей с различными, сквозными интересами лежат в основе инноваций.
Команды Разработки, работающие над комплексными продуктами, постоянно борются с двойственной природой формы и содержания. Мы склонны формировать организационные юниты вокруг активностей по разработке. Более того, формат и содержание являются просто социальными конструктами и несколько произвольными категориями: надежность может быть столь же непреодолимым требованием для данной системы, в то время как красота, обратная совместимость или другие проблемы могут преобладать. В каждом случае бизнес выигрывает от того, что Команда Разработки организует себя вокруг наиболее важных бизнес-задач, какими бы они ни были.
Поскольку ваша команда только начинает развиваться и начинает двигаться к созданию Скрам-команды, у вас появляется все больше людей, которые работают как один организационный юнит для выполнения всех функций (планирование релизов, разработка и профессиональный рост). Но рост и зрелость также вызывают дискомфорт, поскольку команды жаждут неструктурированной эффективности, которая была на первых порах существования компании/организации. Тем не менее, чтобы расти и правильно управлять продуктом на рынке, требуется более дисциплинированная организационная структура и легковесное управление.
Культура требует структуры для эффективного функционирования целого. Наиболее эффективное общение всегда происходит локально в рамках привычного, поэтому крайне важно локализовать процесс принятия решений вокруг наиболее важных организационных вопросов. В любой нетривиальной социальной организации важно, чтобы люди могли быстро связать любую интересующую область с наиболее эффективным «местом, куда можно отправиться», когда им нужна информация об этой области или необходимо предпринять действия в этой области.
Простое организационное разделение (то есть иерархия) достаточно в простых доменах, которые имеют дело только с одним набором разделимых задач. Иерархический подход ломается в типичном случае разработки с множеством пересекающихся задач. Это подталкивает к созданию более крупных и более комплексных организационных единиц, которые пытаются решить проблему с экономией на масштабе. Тем не менее, наиболее эффективные рабочие команды — Небольшие Команды, и вам нужно как-то разделить работу между ними.
Однако, ни одна команда не является отдельным островом, а разработка — больше, чем просто совокупность островов. Команды самостоятельно развивают свою идентичность, где естественная ксенофобия (потребности в знакомых лицах) заставляет команды придавать второстепенное значение проблемам, происходящим вне их социального круга. Если вы ограничиваете организацию только одним набором социальных взаимодействий, основанных на одном разделении, вы теряете идеи, питающие инновации.
Скорость принятия решений имеет первостепенное значение. Некоторые вопросы являются неотложными («На нас нападает другое племя, и мы должны защититься от них»), в то время как другие, хотя и важны, терпят или даже требуют более продолжительного обсуждения («Каково лучшее место для нового конференц-зала?»). Термин «разделение слоев» описывает связанные процессы, которые протекают с разными скоростями, после представления о тектонических плитах, которые движутся друг через друга, например, приводят к землетрясению. И архитектура зданий, и область архитектуры программного обеспечения приняли это понятие, чтобы описать структуры или проблемы с различными скоростями изменения в плотно связанной системе. Компания должна структурировать свою организацию, чтобы иметь возможность быстро реагировать на запросы первой категории, не снижая ее эффективность для запросов второй.
Другим Аджайл-принципом является то, что мы обращаемся наружу: то есть мы фокусируемся на конечном пользователе, рынке и клиентах, а не на инструментах и технологиях, которые мы используем для своей работы. Организация должна также адресовать эту проблему, поскольку она является ключом к ценностному предложению и построению всего Потока Создания Ценности разработки.
В конце концов, структура организации должна иметь столько же общего со структурой процесса, как и со структурой продукта.
Поэтому,
Организуйте разработку в Небольших командах (примерно 5 человек), в соответствии с наиболее важными задачами для создания ценности. Дополните эту структуру небольшим количеством сквозных структур для второстепенных, но важных задач, не забывая, что эти структуры являются лишь оптимизацией того, что в противном случае является открытой средой неограниченного сотрудничества.
Рассмотрим организацию, которая создает мобильный телефон. Можно организовать свои Скрам-команды вокруг того, что может быть поставлено на рынок или главной функциональности. Таким образом, может быть одна команда для адресной книги, другая для календаря и другая для более традиционных функций телефона: см. Области Ценностей. Это основные задачи бизнеса. Но могут быть группы, которые собираются вместе, чтобы определить методы, политики и корпоративные стандарты (например, внешний вид пользовательского интерфейса), в состав которых входят представители каждой Скрам-команды. Эти группы не создают продукт, а служат информационным обменом и источниками стандартов, которые определяют развитие. В здоровых организациях существует почти полное совпадение между членством в этих последних группах и членством в Команде Разработки.
В большинстве сред основная организационная структура отражает структуру основных заинтересованных сторон, которой обычно является рынок. По этой причине мы организуем Скрам-команды не вокруг внутренних артефактов, ни в соответствии с доменной экспертизой, а скорее вокруг того, что может быть поставлено на рынок, например, фич.
Организация вокруг фич или того, что может быть поставлено на рынок, также является преимуществом для восприимчивости рынка и сокращения времени выхода на рынок (T2M), так как команда является центром всей работы, необходимой для реализации фичи. Это сохраняет координацию в организационных рамках. Если рабочие подсистемы или основные компетенции определяют организационную структуру, то изменения на рынке или в сущности поставки, вероятно, повлекут за собой координацию между несколькими командами или организациями, что приведет к снижению оперативности и увеличению времени принятия решений.
Если это единственная структура, она поддерживает только взгляд на рынок и маргинализирует множество других важных бизнес-задач. Чтобы эта структура работала, она должна быть дополнена сквозными структурами, которые поддерживают второй уровень эффективности коммуникации, например, связанные с основными компетенциями. Таким образом, этот паттерн почти всегда используется вместе с паттерном Birds of a Feather и паттерном, описанным в разделе Domain Expertise in Roles. Организационная структура рушит стены, которые естественно образуются между командами. Сделайте так, чтобы продуктовые усилия в компании были соединены друг с другом и с исполнительным руководством через MetaScrum. Команды, которые развили Team Pride (чувство гордости), будут более эффективными, поскольку эта или другая эквивалентная сила будет стимулировать ответственность. Это помогает обеспечить работу этих структур, несмотря на ксенофобские эффекты членства в команде.
Свяжите все это вместе с открытой средой без стен и без дверей. Команды разработки — это всего лишь подразделение, занимающееся разработкой, и здесь не должно быть помех, ограничивающих свободное взаимодействие между разработчиками между командами. Добавьте небольшие комнаты поблизости для коротких периодов тишины, серьезных размышлений и небольших встреч.
Любая составляющая ценности может быть использована в качестве критерия организации. Например, Скрам высоко ценит колоцированность членов команды, поэтому базовые границы организации, скорее всего, соответствуют Колоцированным командам.
✥ ✥ ✥
Обратите внимание, что в хорошем Скраме есть два уровня закона Конвея: один основан на фокусе на продукте, а другой — на областях компетенции. На поверхностном уровне мы организуем команду в соответствии с процессом; это является главной задачей как внутренних, так и внешних аспектов процесса. Итак, три сферы владения процессом:
- Команда Разработки, которая владеет решениями о правильном использовании технологии и техник при создании продукта;
- Владелец Продукта, который владеет определением и направлением продукта; а также,
- Скрам-мастер, который несет ответственность за то, что этот процесс поддерживает регулярную поставку Командой Разработки.
В Скраме Команды Разработки – фиче (продуктовые) команды. То есть основной принцип организации Скрам-команды заключается в том, что она должна соответствовать последовательности поставок фич вдоль всего потока создания ценности. Внутри Скрама существует слабая, поверхностная иерархическая организация, которая объединяет несколько Команд Разработки с общим Владельцем Продукта в организации, называемой Scrum of Scrums. Каждая Команда Разработки в рамках одного продукта разрабатывает один набор фич одновременно. Со временем ключевые бизнес-драйверы, общие бизнес-знания и артефакты Потока создания ценности свяжут эти функции. В Команде Разработки нет признанных титулов или подкоманд.
Существует много путей распределения работы по фиче-командам. Команда Разработки может поставлять функциональность для определенного рынка (смотри Organization Follows Market) или разработать продукт для некоторого подмножества корпоративного технологического спектра (одна команда для телефонов, а другая для планшетов, хотя оба используют большую часть одного и того же программного обеспечения). В общем, каждая команда должна быть сформирована вокруг некоторого продукта, который учитывает компонент ценности организации: смотри Value Stream Fork. Тем не менее, Скрам не одобряет структуру, где каждая Команда Разработки владеет одной частью продукта или только его сборкой. Если члены какой-либо отдельной команды могут разрабатывать только одну часть системы, им необходимо будет координировать множество решений по разработке с другими командами. Командам становится трудно принимать решения локально, а результаты включают задержку обратной связи и передачи.
На втором уровне Закона Конвея Скраме, люди организуются вокруг областей компетенций, в которых навыки повышают ценность. Эти Birds of a Feather помогают участникам углубить свои знания в какой-либо профессиональной или технической области, когда они делятся идеями или проходят обучение. У большинства людей есть врожденное желание совершенствоваться, и эти группы питают индивидуальную гордость, когда члены команды учатся и растут. Но опять же, эти группы неформальны, и любой член команды может принадлежать к нескольким Birds of a Feather, а также к своей собственной Скрам-команде. Смотрите также Domain Expertise in Roles.
Границы и идентичность Команды Разработки, как и Скрам-команды являются явными. Понимание идентичности команды – ключ к Team Pride и эффективной работе организации, поскольку идентичность команды создает социальный контекст, который помогает оптимизировать принятие решений. Любое понятие организационной идентичности, выходящее за рамки этих двух понятий, должно быть негласным, а не явным или контролируемым. Опять же, в Команде Разработки нет официальных титулов, кроме «Разработчик». Если есть только одно неприкосновенное правило, так это то, что ни один человек не может использовать свою негласную позицию для того, чтобы отвергнуть командный консенсус или каким-либо другим образом ослабить дух командной работы, как в «Духе игры». Совместно разработанные Нормы поведения являются сильным предвестником идентичности команды.
В ролях может быть экспертиза на индивидуальном уровне, тогда важно дополнить этот паттерн Cross-Functional Teams везде, где это возможно, чтобы оптимизировать возможности локального принятия решений.
Оригинальный Закон Конвея появился из разработки программного обеспечения. Существует множество мифов, связанных с происхождением и практикой закона Конвея. Долгое время считалось, что объектная ориентация поддерживает закон Конвея, локализуя рыночные интересы внутри классов.
Это полуправда; классы, как правило, инкапсулируют долгосрочные проблемы основных компетенций организации. Тем не менее, объектная ориентация, по-видимому, фокусируется на связи между экспертизой разработчиков и артефактами, которые они разрабатывают, а не на какой-либо связи с рынком или прецедентами использования. Опасения за соответствие рыночной структуре должны превзойти тревогу о мировоззрении разработчиков их процесса и продукта.
Водопадный стиль разработки достиг своего расцвета. В водопадных организациях основная организационная структура состояла из следующих этапов процесса: анализ требований, проектирование, внедрение и тестирование. Согласно закону Конвея, организационная структура отражала эти проблемы процесса.
Программное обеспечение также может очень хорошо отражать эти этапы: например, сервис-ориентированная архитектура (SOA) будет отражать большую часть требований к добавленной стоимости на уровне интеграции служб, в то время как отдельные службы находятся на другом уровне. В то время как подходы к разработке программного обеспечения времен водопада пытались привести рыночные проблемы (варианты использования) в соответствие с архитектурой, организационная структура пересекала эту таксономию. То же самое можно сказать и об организации сборочных линий на фабриках.
Так как Команды Рарзработки – фиче-команды, они должны фокусироваться на одной фиче в один момент времени (как в Swarming). Основным результатом Скрама для рынка является фича, и в этом смысле есть соответствие между структурой команды и рынком. Скрам ничего не говорит об архитектуре продукта, но в духе Аджайла препятствовать индивидуальному владению кодом. Каждая Команда Разработки имеет право работать в любой части продукта. Можно сказать, что Скрам балансирует выгоду организации
Можно сказать что скрам создает баланс между преимуществами инкапсуляции и направленностью команды на рыночный результат. Владелец Продукта, с помощью Команды Разработки, управляет тем, как обрабатывать взаимосвязи функций, возникающих с течением времени.
Рассмотрим, например, что одна команда может реализовать фичу ожидания вызова для телекоммуникационной системы, в то время как другая реализует переадресацию вызовов. Из-за эмерджентности вы не всегда можете предсказать цену разрешения зависимостей между любыми двумя Элементами Бэклога Продукта (PBI), поэтому в целом невозможно преодолеть эту проблему, назначив PBI командам. В любом случае, преждевременное назначение работы командам может сделать невозможной эффективную работу людей над сложными частями (особенно теми, которые связаны с взаимодействием между частями) и ограничить самоорганизацию на уровне Скрам-команды. Эти две фичи могут быть сильно взаимозависимыми, но Скрам структура не дает приоритетный статус этим взаимодействиям. В этом случае, вероятно, было бы лучше, если бы обе фичи разрабатывала одна команда. Распределение работы между командами основывается на постоянном планировании и совместном принятии решений, начиная с Планирования Спринта. Хорошая Скрам-команда стремится разделить работу между Командами Разработки посредством тесного, но ограниченного по времени взаимодействия между Владельцем Продукта и Командами Разработки, например, в случаях постоянной Актуализации Бэклога Продукта, а также на Планировании Спринта.
Обычно менеджмент – компонент организационной структуры, хотя есть некоторые Скрам организации, которые работают без менеджеров (например, смотрите недавнее видео о гибкой трансформации в Bosch Software Innovations. Этос Скрама имеет тенденцию фокусироваться на людях и продукте, и фокус воплощен в ролях Скрама (как Команда Разработки и Команда Владельца Продукта) и организациях, которые они представляют. Если организация с уже существующими менеджерами намеревается внедрить Скрам, для Скрама слишком просто отторгнуть управленческую часть организации как потустороннюю. В таких ситуациях, когда нет возможности создать организация без менеджмента, очень важно Вовлекать Менеджеров.
