dEmindED (deminded) wrote,
dEmindED
deminded

Немного о scrum и Стаффорде Бире.

Пока мир менеджмента переживает столкновение с идеей бирюзовых организаций, острою фазу любви и ненависти к самоорганизующимся командам и взрыв интереса к гибким методам управления, писать особо не о чем. Но так как на работе мы уже несколько лет «scrum’им» на 1С, а Сашенька адаптирует процесс под обучение географии пятых классов, то про него, родимого, и буду писать. Но писать буду в своем контексте, так как мой сенсей говорил мне когда-то: «всегда применяй свой стиль».

Имеем agile в реализации scrum, что есть определенная философия, распадающаяся на принципы, процессы и артефакты. Насколько эта философия с этим фреймворком обеспечивают жизнеспособность команд? На этот вопрос не ответить, но чтобы начать искать ответ на вопрос, насколько они более отвечают этой задаче, чем другие, я открываю модель жизнеспособного предприятия (VSM).

Все начинается с базовых понятий организационной единицы — команды (scrum team). Бир при рассмотрении организации как системы обратил внимание на ее жизнеспособность как универсальное свойство и имманентную самоцель. И первым пунктом при рассмотрении жизнеспособности (способности поддерживать самостоятельное существование в заданном окружении) является ее автономия.

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

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

Но этим дело не ограничивается. По Биру жизнеспособная система есть холон в холархии жизнеспособных систем. И хотя фреймворк ничего не говорит о системе, в которую включена команда, он напрямую утверждает, что сама команда состоит из других жизнеспособных систем — ее участников. Казалось бы, то, что члены команды — люди, само по себе должно гарантировать, что она состоит из жизнеспособных систем; но мы-то рассматриваем команду не как систему – коллектив, а как систему – производителя продукта, и в этом отношении ее составляют не люди, а специалисты. Поэтому для нас важнее, что идеология agile предполагает специфическое отношение к специалистам как к автономным жизнеспособным системам: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им». Требование профессионализма относится к их внутренней автономности (что они способны осуществлять необходимую деятельность), а требование мотивированности — к внешней (что не надо их заставлять и за них принимать решения).

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


Немного о SCRUM и Стаффорде Бире 1

Итак, наши разработчики (development team) — это подсистема 1. Они взаимодействуют с разными, но пересекающимися частями продукта и окружения, а также в процессе деятельности используют общие ресурсы, что частично поглощает поступающее к ним по горизонтальным каналам разнообразие и обозначается на схеме связывающей их «гармошкой». Фреймворк ничего не говорит о содержании их деятельности, которая может в теории быть любой, поэтому эта часть взаимодействия выходит за рамки темы.

Однако наличие общего поля работы требует устранения возможных колебаний. В модели Бира за это отвечает подсистема 2 — демпфер колебаний, который осуществляет не регулятивные, а исключительно координирующие функции между элементами системы 1. Артефакты, которые предоставляет scrum для координации работы сотрудников, это scrum-доска. Через не участники согласуют планы для предотвращения одновременного выполнения одной и той же работы. Доска носит исключительно информационный характер, ни в коем случае не директивный.

Немного о SCRUM и Стаффорде Бире 2

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

Фреймворк предоставляет для этого следующие инструменты: цель спринта (sprint goal), бэклог спринта (sprint backlog) и обязательства, принятые на себя на спринт командой (commitment) составляют нисходящий поток командного канала. Также к усилителю на нисходящем командном канале можно отнести предусмотренную фреймворком политику определения готовности (definition of done). Восходящий канал «отчетности» включает информацию на ежедневной встрече (daily meeting) о том, кто что делал вчера.

Помимо этого подсистема 3 подпитывается восходящей информацией от подсистемы 2, предоставляемой в агрегированном виде — это диаграмма сгорания (burn-down chart). В этом случае, если происходит разбалансировка работы, система 3 может вмешаться (участники команды могут предложить друг другу помощь с провисающими задачами, недогрузкой или перегрузкой отдельных разработчиков).

Немного о SCRUM и Стаффорде Бире 3

Эти потоки обладают крайне низким уровнем разнообразия, чтобы избежать перегрузки командной подсистемы системы 1, поэтому для успешного поддержания текущей деятельности жизнеспособная система должна содержать подсистему 3*, которая напрямую обрабатывает избыточное разнообразие производственных процессов, не обращаясь к «официальной отчетности» системы 1 перед системой 3, и поставляет данные системе 3 в «заглушенном» (например, в обобщенном) виде для выработки политик и принятия решения. Наиболее близкая метафора — это система аудита. Я не нашел отвечающих за нее артефактов и процессов в scrum, хотя во фреймворках разработки они присутствуют: например, практика анализа кода (code review) и непрерывной инспекции (continuous inspection).

Немного о SCRUM и Стаффорде Бире 3 star
Кто выполняет функции подсистемы 3, кто отвечает, чтобы текущая работа команды протекала гладко, чтобы обязательства не забывались, чтобы команда обеспечивалась ресурсами, кто ставит цель? Я склоняюсь к следующему разделению: работа над продуктом в целом делится на стратегическую часть (выбор направления развития продукта) и исполнительную (работа по развитию продукта). К области «здесь и сейчас» я отношу именно вторую, исполнительную часть, т.е. работу внутри спринта, поэтому процесс выбор и постановка цели на спринт (sprint goal), определения плана спринта (sprint backlog) и формирования обязательств команды (commitment), коотрые производится всей командой (scrum team) с участием владельца продукта на планировании спринта (sprint planning), я вынес за рамки третьей системы.

В задачи системы 3 я включаю следующие моменты. Работу внутри спринта ведет команда разработки (development team) автономно, владелец продукта уже не вмешивается. Отслеживание работы по спринту осуществляется ежедневно на ежедневной встрече (daily meeting), а за устранением препятствий (impediment) следит scrum-мастер, для чего предусмотрен алгедонический канал: вопрос разработчикам о том, какие препятствия мешают им работать на достижение цели спринта. Фактически поддержание работы лежит на самой команде разработчиков — hence самоуправление.
Поднимаемся выше. Жизнеспособная организация не сможет существовать только «здесь и сейчас», ей надо заглядывать в неизвестное, в будущее, а также взаимодействовать с общим окружением системы как с целым, а не только с окружением каждого из элементов. По Биру эти функции лежат на подсистеме 4. Здесь сосредоточены срезу несколько задач.

Во-первых, это взаимодействие с окружением как с целым и моделирование этого окружения для команды. Эту функцию для команды выполняет владелец продукта (product owner). Именно он для команды «отражает» внешний мир, нужды пользователей продукта и других стейкхолдеров. И ему для снижения входящего разнообразия фреймворк предоставляет такие инструменты, как бэклог продукта (product backlog) — набор требований, описанный в форме пользовательских историй. Фреймворк не содержит артефактов для систематизации разных требований разных стейкхолдеров к продукту (Stakeholders’ requirements), но и не ограничивает в их использовании (можно искать их у тов. ailev).

Немного о SCRUM и Стаффорде Бире 4
Фреймворк предлагает средства усиления исходящего разнообразия и «приглушения» входящего — это sprint review, периодика которого ограничивает входящий поток, а демонстрация командой результатов разработки напрямую заказчику усиливает исходящий (личное общение — очень сильный усилитель для канала). Для случая разработки есть такие усилители, как инструкции пользователя или обучающее видео, но это, опять же, за рамками фреймворка.

Второй блок подсистемы 4 — это работа с «будущим». Для этого ей нужна модель работы самой системы, которая может использоваться для динамического моделирования в сценариях что/если, и которая обеспечивается данными системы 3. Scrum предоставляет владельцу продукта данные о скорости выполнения командой задач (velocity), оценкой самих задач (user story estimates) и обеспечивает инструментом оценки оставшегося объема работ в бэклоге (кумулятивная диаграмма, backlog cumulative flows), чтобы он мог динамически оценивать потенциальные сроки реализации тех или иных требований при редактировании бэклога (или изменении мощности команды) при выработке стратегии, которая выражается в расстановке приоритетов (backlog grooming and prioritizing).

Самая сложная часть, самое узкое место, которое обрабатывает максимальное объем разнообразия — это взаимодействие система 4 с системой 3, и разнообразие, порожденное одной, должно поглотить разнообразие, порожденное другой системой. Как обеспечивается этот процесс в scrum?

Первое поглощение разнообразия производится при оценке пользовательских историй (user story estimation), которую выполняет команда, для чего существует набор инструментов типа planning poker. Это существенно снижает разнообразие информации, поступающей в систему 4. Дополнительное снижение разнообразия производится за счет «безразмерной» шкалы оценки в условных единицах, показывающих только сравнительную сложность задач и мощность команды (velocity), что позволяет подсистеме 4 абстрагироваться от тонкостей реализации.

Второе поглощение — это приоритезация бэклога (priorities) по бизнес-ценности требований (business value estimates), которую выполняет владелец продукта. Третье — во время планирования спринта (sprint planning) и обзора спринта (sprint review) остаточное разнообразие поглощается в совместном обсуждении пользовательских историй команды разработки с владельцем продукта и заинтересованными лицами. Результат — это цель и план спринта, которые и задают подсистеме 3 направление текущей работы.
Немного о SCRUM и Стаффорде Бире 4-3

У жизнеспособной системы существует еще одна подсистема — подсистема 5, отвечающая за ее самоопределение и самоосознание, а также тонкую настройку баланса между задачами «здесь и сейчас» и задачами на развитие и изменение. В scrum эта подсистема реализована в форме ретроспективы спринта (sprint retrospective), на которой команда рефлексирует по поводу своей работы. Это мероприятие призвано обрабатывать все остальные всплывшие «проблемы», оставшиеся от взаимодействия 3 и 4 подсистем, а также обрабатывать алгедонические сигналы (хорошо или плохо идут дела на «нижних уровнях» холархии, т.е. у отдельных участников), с которыми не справилась система 3 (на ежедневных встречах, daily meeting). Характерно, что по Биру пятая подсистема должна представлять собой мультинод, и это соответствует коллегиальному характеру обсуждения на ретроспективе. К пятой подсистеме Бир относил еще и такое явление, как культуру организации, которая как губка впитывает лишнее разнообразие — решает множество вопросов неявным образом. Эту роль призвана выполнять философия agile, суть которой можно найти в agile-манифесте (agile manifest).

Немного о SCRUM и Стаффорде Бире 5

Ретроспектива предполагает участие владельца продукта, ведь он персонифицирует для команды само назначение системы — продукт, который она производит. И именно он выступает для внешней системы олицетворением все целевой системы, «воротами» в нее, так как вся целевая система является элементом внешней надсистемы. Подсистема 5 одновременно выполняет функцию отражения системы для внешней системы и в то же время осуществляет самоопределение целевой системы. Похожая реализация существует в холакратическом фреймворке, где ведущий круга (lead link) является «носителем функции» всего своего круга для внешнего супер-круга.

Итак, пятая система "замыкает" этот уровень рекурсии, сновая становясь элементом 1 надсистемы нашей целевой системы, и мы получаем полную картину.

Немного о SCRUM и Стаффорде Бире

Напоследок я обращу внимание еще на несколько вещей. Для организации «продуктовая команда» выступает черным ящиком, а для команды «черным ящиком» выступает работа каждого разработчика, что необходимо с кибернетической точки зрения для предотвращения перегрузки разнообразием метасистем каждого уровня. Более того, scrum жестко ограничивает роли метасистемы — она выполняет обеспечивающие функции (подавляет колебания, сохраняет целостность, планирует деятельность…) и не допускает разрастания командных каналов: scrum-мастер не вправе давать указания разработчикам, а владелец продукта вправе только расставлять приоритеты, но не может определять объем взятых в спринт задач или вмешиваться в работу команды. Наконец, сам формат взаимодействия (итерационный, регулярный, ограниченный спринтом) также является мощнейшим поглотителем разнообразия, неизбежно порождаемого сложной творческой совместной работой.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment