На чем фокусируется гибкая команда

Гибкие команды для управления в условиях неопределенности

Методы гибкого управления, выраженные в принципах Agile, стали неотъемлемой частью change management. Пришедшие из области программирования, управленческие подходы теперь востребованы во всех отраслях. Понимание того, …

Методы гибкого управления, выраженные в принципах Agile, стали неотъемлемой частью change management. Пришедшие из области программирования, управленческие подходы теперь востребованы во всех отраслях. Понимание того, как работают гибкие методы и внесение их в арсенал базовых инструментов управления, является необходимостью для эффективных руководителей.

В основе гибких методов лежит работа подвижных групп сотрудников. Поэтому в круг моего внимания попало описание деятельности таких коллективов, сделанное Darrell K.Rigby, Jeff Sutherland, Andy Noble. Они выделили особенности маневренных команд, которые важны для понимания сути гибких методов управления. Опираясь на них, ниже емко сформулируем ключевые моменты, что поможет нам быстро разобраться в вопросе и увидеть границы применимости.

Что собой представляют гибкие команды

Под гибкими инновационными командами принято понимать группы сотрудников, находящиеся в контакте с потребителями и способные быстро адаптироваться к меняющимся условиям. Они состоят из небольшого количества людей и являются межфункциональными объединениями (включают сотрудников разных функциональных отделов, объединившихся для решения одной проблемы).

Гибкие группы помогают воспользоваться творческим потенциалом компании.

Назначение

Такие подвижные организационные единицы подходят для:

Гибкие команды предназначены для решения сложных проблем (с высокой неопределенностью).

При этом важным условием является возможность участников команды тесно взаимодействовать с пользователями (внешними или внутренними), разрабатываемого ими решения.

Управление гибкими командами

Команды являются в значительной степени самоуправляемыми. Ответственность за деятельность, направленную на инновационные решения, лежит на участниках команды. Это уменьшает в организации уровни целеполагания и контроля, освобождая старших руководителей от операционной деятельности. Задачей менеджмента является:

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

Алгоритм деятельности гибких команд

В работе гибких групп можно выделить общей алгоритм деятельности:

Деятельность команд не привязана к четким планам, а направлена на создание ценности в меняющихся условиях.

Источник

3. АНАТОМИЯ AGILE

3.1 КОМАНДА AGILE

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

3.1.1 РАЗМЕР КОМАНДЫ

3.1.1 РАЗМЕР КОМАНДЫ

Оптимальный размер команды гибкого проекта — 7 человек, максимальный размер — 12 человек. Команда должна быть компактной, так как при большем количестве участников затруднительно поддерживать тесные, стабильные и эффективные коммуникации, которые требуются для работы в динамичном режиме гибких подходов.

Если для разработки одного продукта требуется большее количество ресурсов, то недопустимо увеличивать размеры команды сверх рекомендованного, нужно декомпозировать продукт на более мелкие «подпродукты» и/или использовать специальные инструменты масштабирования команд гибких проектов (например, LeSS, SAFe и подобные, в том числе описанные в разделе 1.3).

3.1.2 КОМПЕТЕНЦИИ И ПОЛНОМОЧИЯ

3.1.2 КОМПЕТЕНЦИИ И ПОЛНОМОЧИЯ

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

Строго не рекомендуется вводить уровни иерархии внутри команды (не путать с уровнями компетентности по тем или иным направлениям). Некоторые из Agile-фреймворков (в частности, Scrum) вообще требуют «плоской» команды, где у всех членов команды, за исключением владельца продукта и Scrumмастера, одна и та же роль — разработчик продукта (то есть не допускаются роли «аналитик», «тестировщик», «дизайнер», могут быть только разработчики, имеющие схожие компетенции) (рисунок 6).

Команда, как совокупность участников:

• владеет бэклогом спринта команды;
• оценивает бэклог после уточнения с владельцем продукта;
• определяет, необходимо ли изменить бэклог спринта в ходе спринта;
• отвечает за управление процессом работы в ходе спринта.

3.1.3 КРОСС-ФУНКЦИОНАЛЬНОСТЬ

3.1.3 КРОСС-ФУНКЦИОНАЛЬНОСТЬ

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

Не обязательно, чтобы все сотрудники обладали всеми навыками на одинаковом уровне, но по возможности стоит стремиться к модели «все члены команды умеют все, что нужно» (например,
в ИТ-проекте аналитики умеют программировать и тестировать, разработчики — разрабатывать интерфейс пользователя, работать с пользовательскими требованиями и тестировать). Товарищи по команде должны уметь подстраховать коллег и помочь ключевому сотруднику, пусть не так быстро и не на том уровне качества, но суметь завершить задачу, попутно развивая и отрабатывая свой навык в смежной сфере. Иногда используется термин «T-shape специалист». В данном определении «Т» визуально имитирует диаграмму компетенций специалиста, где верхняя перекладина — это широкие, но не обязательно глубокие знания во всех необходимых сферах компетенции, а вертикальная черта — глубокие, экспертные знания в одной из областей. Таким образом, команда, состоящая из T-shape специалистов, заведомо является кросс-функциональной.

3.1.4 САМООРГАНИЗАЦИЯ

3.1.4 САМООРГАНИЗАЦИЯ

Гибкие подходы предполагают делегирование существенных полномочий команде. У участников команды должна быть возможность самостоятельно определять, как будет сделана работа (с учетом общих правил организации, например архитектурных стандартов, стандартов информационной безопасности, особенностей производственного процесса). Целеполагание — что должно быть сделано — исходит от заказчиков и заинтересованных сторон проекта, а элементом, связующим все заинтересованные стороны, является владелец продукта. Как правило, команде делегируются:

При стандартном применении гибких подходов самоорганизация команды допускает отсутствие роли руководителя проекта (или существенное сокращение его функций и полномочий), но обязательно выделяется роль владельца продукта — члена команды, отвечающего за успешность продукта, а также роль Scrum-мастера (название роли взято из конкретного фреймворка Scrum, но de facto эта роль стала уже общепринятой в Agile в целом). Фактически роль классического руководителя проекта распадается на две — владельца продукта и Scrum-мастера. При этом роли обязательно принадлежат разным лицам, совмещать их не рекомендуется.

3.1.5 РАЗМЕЩЕНИЕ КОМАНДЫ

3.1.5 РАЗМЕЩЕНИЕ КОМАНДЫ

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

3.1.6 ПОДБОР И ОБУЧЕНИЕ СОТРУДНИКОВ AGILE-КОМАНДЫ

3.1.6 ПОДБОР И ОБУЧЕНИЕ СОТРУДНИКОВ AGILE-КОМАНДЫ

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

При организации обучения обратите внимание на следующие рекомендации:

3.1.7 ОЦЕНКА ЭФФЕКТИВНОСТИ РАБОТЫ КОМАНДЫ

3.1.7 ОЦЕНКА ЭФФЕКТИВНОСТИ РАБОТЫ КОМАНДЫ

Поскольку Agile-подход предполагает, что самоорганизующаяся команда максимально автономна, ключевые показатели эффективности (КПЭ) должны быть едиными для всей команды, а не индивидуальными. Оценивается результативность команды в целом, никто не фокусируется на оценке индивидуального вклада каждого члена команды. Этот принцип приводит к следующим эффектам:

Какие именно командные КПЭ стоит установить в данном конкретном случае, зависит от специфики проекта/задачи, предметной области, корпоративной культуры. Тем не менее можно сформулировать базовые КПЭ, которые применимы всегда или почти всегда (возможно, с определенной модификацией и доработкой). Рекомендуется рассмотреть следующие глобальные (продуктовые) КПЭ:

Рекомендуется использовать также следующие локальные (операционные) КПЭ:

Источник

Как объяснить бабушке, что такое Agile за 15 минут с картинками

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.

Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».

У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.

Это команда разработчиков. Те, кто будет строить рабочую систему.

Пропускная способность

Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.

Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.

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

Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.

Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.

Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.

Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.

Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.

Принятие решений

Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.

Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.

Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.

Владелец ИТ-продукта должен постоянно со всеми общаться

Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.

Компромисс между краткосрочным и долгосрочным мышлением

Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале — все три одновременно, но в реальности приходится выбирать.

Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.

Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.

Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.

Между ролями в Scrum существует здоровое противостояние

Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.

Компромисс между разработкой нового продукта и улучшением старого

Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

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

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.

Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.

Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.

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

Несколько команд

Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

Источник