1 agile: Kanban команды PVS-Studio. Часть 1: agile

Scrum Foundation 1. Управление проектами с использованием гибких подходов

PMI Authorized Training Partner

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

В отличие от таких всеобъемлющих подходов к управлению проектами, как, например, стандарты Института Управления Проектами (PMI)® PMBOK® Guide, Скрам изначально предназначался для разработки программного обеспечения в условиях часто меняющихся требований. При этом Скрам (Agile) больше ориентирован на сам процесс разработки, чем на процесс управления. Эта технология хорошо дополняет любой из классических процессов управления и может быть с ним интегрирована при разработке даже очень больших IT проектов.

В настоящий момент Agile практики стали частью PMBOK® Guide.

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

Аудитория курса:

• Разработчики программного обеспечения – члены команд разработки, тим-лиды (старшие групп разработки).
• Специалисты, желающие освоить роль Product Owner или Scrum Master в Scrum-командах.
• Менеджмент Scrum-команд, желающий познакомиться с особенностями работ внутри команды.

Курс «Agile-Scrum Foundation 1. Управление проектами с использованием гибких подходов» дает  для подготовки к сертификациям Института Управления Проектами (PMI)^® и PDU для продления имеющихся у вас сертификаций в соответствии с действующими правилами:

+ Описание курса на официальном сайте PMI

PMI является зарегистрированной маркой Института Управления Проектами.
PMBoK является зарегистрированной маркой Института Управления Проектами.

Agile — Scrum Foundation 1. Управление проектами с использованием гибких подходов

Высшее образование онлайн

Федеральный проект дистанционного образования.

Я б в нефтяники пошел!

Пройди тест, узнай свою будущую профессию и как её получить.

Химия и биотехнологии в РТУ МИРЭА

120 лет опыта подготовки

Международный колледж искусств и коммуникаций

МКИК — современный колледж

Английский язык

Совместно с экспертами Wall Street English мы решили рассказать об английском языке так, чтобы его захотелось выучить.

15 правил безопасного поведения в интернете

Простые, но важные правила безопасного поведения в Сети.

Олимпиады для школьников

Перечень, календарь, уровни, льготы.

Первый экономический

Рассказываем о том, чем живёт и как устроен РЭУ имени Г.В. Плеханова.

Билет в Голландию

Участвуй в конкурсе и выиграй поездку в Голландию на обучение в одной из летних школ Университета Радбауд.

Цифровые герои

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

Работа будущего

Как новые технологии, научные открытия и инновации изменят ландшафт на рынке труда в ближайшие 20-30 лет

Профессии мечты

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

Экономическое образование

О том, что собой представляет современная экономика, и какие карьерные перспективы открываются перед будущими экономистами.

Гуманитарная сфера

Разговариваем с экспертами о важности гуманитарного образования и областях его применения на практике.

Молодые инженеры

Инженерные специальности становятся всё более востребованными и перспективными.

Табель о рангах

Что такое гражданская служба, кто такие госслужащие и какое образование является хорошим стартом для будущих чиновников.

Карьера в нефтехимии

Нефтехимия — это инновации, реальное производство продукции, которая есть в каждом доме.

Agile и классическое проектное управление: в чем разница подхода?

23 Авг 2019

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

Классический подход

Давайте вспомним основные принципы классического и гибкого подходов.
Классический проектный подход (еще называют «каскадная модель», «водопадная модель») заключается в том, что вы последовательно реализуете этапы проекта. Например, планирование, разработку, тестирование и поставку результатов работ Заказчику. Присутствует вертикаль управления — Руководителю проекта делегированы полномочия, он управляет командой и ресурсами, отчитывается Заказчику и Куратору (Спонсору) проекта. Руководитель проекта составляет план проекта, который утверждается Заказчиком, и команда действует согласно ему. Только в конце проекта готовый продукт передается Заказчику.

Классический подход

Agile или Гибкий подход

Об истории применения и развития гибких подходов можно почитать в нашей статье «Неизвестная история Agile»

Напомним ключевое:

Еще с 30-х годов XX века практики и теоретики менеджмента искали пути повышения эффективности работы и избавления от потерь. Появился цикл Деминга (PDCA), бережливые методы производства в Тойоте, понимание негативного влияния простоев, перепроизводства, неравномерной работы, перегрузки сотрудников, накопления запасов и др.

В 1986 году опубликована статья японских исследователей Икуджиро Нонака и Хиротака Такеучи «New New Product Development Game», в которой иллюстрировались потери времени и информации при передаче продукта последовательно от проектировщика разработчику, от разработчика тестировщику и так далее. Авторы статьи рекомендовали специалистам последующих стадий включаться в работу раньше, даже если продукт еще не полностью разработан, чтобы сэкономить время на создание продукта. По сути, предлагается кроссфункциональная команда.

В 1993 году Джефф Сазерленд и Кен Швабер предложили фреймворк Scrum, который базируется на самоорганизации небольшой команды, содержит короткие итерации разработки (спринты), по результатам каждого спринта заказчик получает работоспособную и улучшенную версию продукта.

Рассмотрим более подробно, как поставляется продукт в Agile. Начнем с инкрементального подхода – это быстрое создание продукта с ограниченным, но работающим функционалом. Такой подход позволяет быстро проверять и корректировать гипотезы относительно создаваемого продукта и быстро корректировать направления дальнейшей разработки. Например, если Заказчик просит у нас портрет «Моны Лизы», мы делим холст целиком на участки, и каждый участок создаем последовательно. Такой формат не предполагает доработок уже созданных фрагментов, но каждый фрагмент является целостным и его уже можно показывать заказчику, не дожидаясь окончания проекта.

Инкрементальный подход

Итеративный подход заключается в повторении операций для улучшения результатов предыдущего этапа (итерации). В примере с Моной Лизой мы вначале создаем черновик картины целиком, затем постепенно, слой за слоем, итерация за итерацией, приближаемся к итоговому результату. При этом  результаты каждой итерации можно продемонстрировать Заказчику и на основе обратной связи внести корректировки.

Итеративный подход

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

Итеративно-инкрементальный подход

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

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

Резюме

Классическое проектное управление («водопад») основано на последовательности выполнения этапов работ и передаче заказчику готового продукта в конце проекта.

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

Оба подхода имеют свою зону эффективного применения. На основе своего опыта мы сформулировали ключевые различия подходов:

Характеристика	Классический подход	Agile
Поставка ценности (работающего результата)	Происходит в конце проекта	Осуществляется по мере реализации проекта в виде работающих элементов продукта. Используется итеративно-инкрементальный подход.
Проверка гипотез	Как правило, выполняется на предпроектной стадии, до старта проекта	Выполняется командой в ходе проекта для улучшения продукта. Часть гипотез может быть признана несостоятельными
Планирование	Детальное, до конца проекта. Для оценки сроков используется Метод критического пути. В проектах с высокой неопределенностью используется метод «набегающей волны».	Эмпирическое, на основе исторических данных о реализованных элементов продукта
Стиль менеджмента, руководства	Вертикаль управления: Управляющий комитет -> Куратор, Заказчик -> Руководитель проекта	Самоорганизация внутри команды. Плоская команда без внутренней иерархии.
Отношение к изменениям	Как правило имеет негативный характер – изменения как следствия реализации рисков и наступления проблем. Требует формального процесса по анализу последствий и пересчету критического пути проекта, анализа альтернатив.	Изменения являются частью процесса разработки. Источником изменений является в т.ч. более лучшее понимание продукта на основе опыта.
Тип мышления, отношений	Как правило определяется культурой организации, зачастую фиксированный mindset	Необходим гибкий mindset для успешной работы в среде с высокой неопределенностью
Метрики проекта	% реализации, отклонение от плана, Метод освоенного объема, прогнозная дата завершения проекта	Диаграмма сгорания задач (Burn down chart), Накопительная диаграмма реализованных функций (Burn Up Chart), Дата выхода на рынок (Time to market)
Наличие руководств, методик	Хорошо структурированы, детально описаны (PMBoK, PRINCE2). Отраслевые стандарты и практики.	Верхнеуровневые фреймворки (например, Скрам). Множество отдельных практик (ежедневное собрание, ретроспектива, спринт и др.)
Область эффективного применения	«Сложные системы» по модели Киневин (Cynefin) – много работ, агентов (стейкхолдеров). Продукт и требования к нему известны, состав работ может быть описан и зафиксирован. Границы проекта фиксированы.	«Запутанные системы» по модели Киневин (Cynefin) – не знаем продукт и/или процесс его создания. Состав работ проекта не определен. Границы проекта размыты

В следующей статье мы планируем рассказать о модели Киневин (Cynefin) для определения к какой группе относится ваш проект.

Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.

 

Смотрите также:

Agile или PMBOK: что выбрать для вашего IT-проекта

Выбор подхода к управлению проектом – первый шаг к успеху. Сегодня пытаются противопоставлять классический PMBOK и гибкий Agile и их вариации, но это неверно. Почему их нельзя сравнивать и можно ли их сочетать в одном IT-проекте, рассказывает эксперт в области Agile и управления проектами Luxoft Training Сергей Шарпак.

Исторический путь PMBOK и Agile в IT

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

PMBOK (от англ. Project Management Body Of Knowledge) буквально расшифровывается как «свод знаний по управлению проектами». По сути, он предлагает систему координат. В самом наименовании подчеркивается, что объем знаний по управлению проектами бесконечен. Чтобы в нем не запутаться, нужен навигатор. И PMBOK – не все знания, которые нужны для управления проектами, а всего лишь подробная «карта».

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

Идею извлечения из опыта повторяющихся шагов стали использовать и в других индустриях. Когда начали применять PMBOK в сфере IT, оказалось, что в области виртуальных объектов классический подход работает не так хорошо, как ожидалось. При работе с физическими объектами результат понятен в самом начале проекта. То есть их можно распланировать, выстроить некую виртуальную модель или чертеж, а затем перейти к фактическому строительству.

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

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

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

Их практики между собой не были согласованы. И в 2001 году 17 представителей таких альтернативных движений встретились, вычленили из них общее ядро и обозначили в виде 4 ценностей и 12 принципов в Agile-манифесте.

Так появилось и само понятие Agile. До принятия манифеста практики назывались lightweight. Но термин Agile лучше раскрывает суть — быть гибким и юрким. Другими словами, в практиках Agile отражены идеи, позволяющие непрерывно пересматривать представление о создаваемом продукте и при этом двигаться в процессе разработки быстро. Все, что вредит гибкости и скорости, отсекается.

Преимущества и недостатки PMBOK и Agile

Если говорить строго, то PMBOK и Agile нельзя сравнивать, поскольку их инструменты предназначены для решения разных задач. Выбор зависит от степени понятности результата или способа его получения. Более того, хорошее знание классического проектного подхода помогает понять Agile-практики. А вот разобраться в них без структуры в голове, которую дает PMBOK, сложнее. В этом случае какие-то области управления могут просто выпасть из внимания. Но это не значит, что у этих подходов нельзя увидеть преимущества и недостатки. О них и поговорим далее.

Главное преимущество PMBOK – возможность предвосхитить значительную долю проблем в проекте, решить их на бумаге дешево и быстро еще до выхода в производство. В некоторых IT-задачах можно предусмотреть путь решения и подводные камни на этом пути, а значит подготовиться к ним. К примеру, при строительстве ЦОДа может возникнуть проблема, когда в результате каких-то внешних работ будет перебит канал связи. Значит, нужно заранее продумать второй резервный канал.

С точки зрения сроков реализации, бюджета и качества результатов использование PMBOK дает определенную уверенность и прозрачность. Но подчеркну, всё это действует только в проектах с высокой степенью понятности. Agile-практиками тоже можно решить понятную задачу. Но это будет дольше и дороже, а при очередной переработке могут возникнуть еще и проблемы с качеством.
Преимущества Agile заключаются в том, что команды в таких проектах гибкие и юркие, не боятся изменчивости, готовы развернуться и быстро перестроиться. Но при этом такой подход не стимулирует к планированию, которое помогает предвосхитить проблемы.

Одной из самых привлекательных черт в Agile-практиках является отношение к человеку. Оно отличается от классического проектного подхода, где людей считают ресурсом. И в этом – серьезный недостаток PMBOK. Так как он исторически зародился в строительной отрасли, поэтому исходит из того, что в задачах, связанных с физическим трудом, работает мотивация «кнута и пряника».

В Agile работа изначально шла с интеллектуально сложными задачами, поэтому система мотивации там иная. В основе таких практик – уважительное отношение к человеку. А основным драйвером в Agile выступает «внутренний огонь». Зажигается он при условии, что люди видят смысл и пользу от своей работы, растут как профессионалы, а также получают некую автономию в решении задач.

Как понять, что лучше подойдет для вашего IT-проекта

В своей практике я столкнулся с тем, что практически про любой IT-проект нельзя однозначно сказать, является ли он полностью понятным и соответствующим рекомендациям PMBOK или на 100% непонятный, поэтому для его решения подходят только Agile-практики.

Дело в том, что большая часть IT-проектов гибридные, неоднородные по составу. Отсюда возникает вопрос, какой подход к ним применить. С одной стороны, ими можно управлять с точки зрения классической технологии, изложенной в PMBOK. Но тогда неясно, что делать с запутанными участками, для которых такой подход работает плохо.

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

Решением здесь может стать сочетание Agile и PMBOK. Гайд по тому, какие инструменты применять и в какой последовательности, как их правильно комбинировать, пока не создан. Учиться приходится самостоятельно.

Рассмотрим несколько случаев, как в гибридных IT-проектах можно сочетать Agile и PMBOK.

1. Проект, в котором стадия неизвестности сменяется классической с понятным решением.

Пример: разработка флагманской модели мобильного телефона.

Начало такого проекта – задача с непонятным решением. Необходимо изучить последние достижения техники, придумать оригинальную начинку телефона. Берем на вооружение Agile-практики, применяем научный метод, экспериментируем и находим какую-то «формулу». В нашем случае – конкретный вариант модели телефона со значительными отличиями от существующих решений. А это значит, проект прошел стадию неизвестности.

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

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

2. Проект с понятным решением в целом и отдельными запутанными участками.

Пример: прокладка IT-инфраструктуры в новом бизнес-центре.

Такой проект в целом является понятным. Он подходит под классический PMBOK. По нему уже отработан перечень мероприятий и есть четкая последовательность действий. Но внутри проекта также может встретиться некий запутанный участок. Там лучше будет применить экспериментальный подход из Agile-практик – выдвинуть ряд гипотез и проверить их на практике.

3. Проект с высокой степенью неопределенности и отдельными понятными участками.

Пример: разработка компьютерной игры.

В проектах по разработке решений для высококонкурентных рынков со множеством игроков использовать классический подход, опираясь на прошлый опыт, не стоит. Здесь нужно создать новый оригинальный продукт и обыграть конкурентов. В это же время они будут пытаться переиграть вас. В подобных проектах не может быть готового решения: это задача с высокой степенью неопределенности. Более того, ее понимание по ходу производства игры будет постоянно меняться. Под решение такой задачи подходят Agile-практики.

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

4. Проект по типу «партизанский agile».

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

При выборе подхода для решения какой-то конкретной задачи по IT-проекту нужно отталкиваться от общего критерия – ясности. Применить его можно к конечному результату проекта (продукту) либо к способу его достижения (процессу получения этого продукта). Если у вас есть ясность в отношении обоих моментов, лучше использовать классический PMBOK.

Если нет ясности по продукту (а у большинства IT-решений на конкурентных рынках конечный результат изначально непонятен), подключаем Agile-практики. Например, с продуктовой неопределенностью помогает разобраться Scrum.

Но непонятность может быть и в отношении процесса. Например, у службы поддержки на обслуживании находятся CRM или ERP-системы клиентов из разных часовых поясов. Задача ясна – обрабатывать инциденты и закрывать их в максимально короткие сроки с высоким качеством. Но при организации процесса могут возникнуть трудности. Организатор может не понимать, как сделать его четким, стабильным и предсказуемым. Эту процессную запутанность можно решить при помощи Agile-практик, например, Канбан-метода или иных.

По моему мнению, постепенно искусственная оппозиция между Agile и PMBOK станет не такой напряженной. Все поймут, что это просто разные подходы для решения разных задач. А в проектных командах нормой станет сочетание этих практик.

Agile PPP, главы 1–5 Заметки для чтения

1.1 Agile Alliance

1. Индивидуумы и взаимодействия превосходят процессы и инструменты
2. Работоспособное программное обеспечение лучше полной документации

Документы не готовятся до тех пор, пока они не возникнут в срочном порядке.

3. Сотрудничество с клиентами лучше, чем переговоры по контракту
4. Реагировать на изменения лучше, чем следовать плану

в общем

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

Чем меньше функций содержится в системе начальной доставки, тем выше качество конечной системы доставки.

2. Даже на более поздних этапах разработки приветствуются изменения требований. В гибких процессах изменения используются для создания конкурентных преимуществ для клиентов.
3. Регулярно доставляйте работающее программное обеспечение. Интервал доставки может составлять от нескольких недель до нескольких месяцев. Чем короче интервал доставки, тем лучше.
4. На протяжении всего периода разработки проекта бизнес-персонал и разработчики должны работать вместе каждый день.
5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимую среду и поддержку и доверьте им выполнение работы.
6. Внутри коллектива наиболее действенный и действенный способ передачи информации — это личный разговор.
7. Основной показатель прогресса при работе с ПО.
8. Гибкие процессы способствуют устойчивому развитию. Ответственные лица, разработчики и пользователи должны иметь возможность поддерживать долгосрочную и постоянную скорость разработки.
9. Постоянное внимание к отличным навыкам и хорошему дизайну повысит маневренность.
10. Простота — искусство максимизировать незаконченную работу — имеет фундаментальное значение.
11. Лучшая архитектура, требования и дизайн исходят от команды организации.
12. Через регулярные промежутки времени команда будет размышлять о том, как работать более эффективно, а затем соответствующим образом корректировать свое поведение.

1.3 Заключение

2.1 Практика экстремального программирования

• Клиенты как члены команды
• Пользовательский материал
• Короткое время выполнения заказа
• Вступительный тест
• Парное программирование
• Подход к разработке через тестирование
• Коллективная собственность
• Непрерывная интеграция
• Скорость устойчивого развития
• Открытое рабочее пространство
• Планирование игры
• Простой дизайн
• Refactor
• метафора

В заключение

Первоначальное исследование

В начале проекта разработчики и заказчики постараются выделить все действительно важные пользовательские материалы. По мере продвижения проекта заказчики будут продолжать писать новые пользовательские материалы. Написание материалов будет продолжаться до завершения проекта.

Эти материалы разработчики оценивают совместно.

• Запрос, разложение и скорость

План выпуска

План итерации

Разработчики и заказчики определяют масштаб итерации, которая обычно занимает две недели.

Даже если весь пользовательский материал не заполнен, итерация завершится в ранее указанную дату.

план миссии

В начале новой итерации разработчик и заказчик вместе составляют план.

• Середина итерации

В середине итерации команда проведет собрание.

итерация

В конце каждой итерации клиенту будет показана запущенная в данный момент программа.

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

Подход к разработке через тестирование

Если вы можете разработать план тестирования до разработки программы

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

Вступительный тест

критерии выбора подрядчика • König Labs

Думаю, нет необходимости рассказывать о том, что такое Agile. Agile де-факто утвердился в ноосфере. Все говорят об Agile. Многие хотят провести Agile-трансформацию. Среди сервисных компаний мнения расходятся. Да, Scrum на уровне работы отдельных команд, но трансформация всех процессов компании…

Зачем? Какие бонусы получит сервисная компания от Agile-трансформации? Если вы хотите работать с большими продуктовыми компаниями, крупным бизнесом и корпорациями, то задуматься об Agile-трансформации следует уже сейчас. Такие заказчики все активнее становятся “гибкими”, масштабируют Agile в своих организациях и будут выбирать подрядчиков “из той же обоймы”.

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

 

По каким критериям выбирают подрядчика?

 

1. Цена
2. Качество
3. Понимание и ориентация на бизнес-цели заказчика
4. Грамотно выстроенные процессы и сертификация по ISO
5. Гибкость и скорость реакции

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

Давайте рассмотрим пример: смоделируем ситуацию с поиском подрядчика.

Disclaimer: Названия, имена, и ситуации, хоть и базируются на реальных кейсах, известных мне, в данном случае являются синтетическими. Любые совпадения – случайны.

Компания-заказчик “Thorns Digital” развивает линейку своих собственных продуктов. При этом существует несколько вспомогательных направлений, до которых никогда не доходят руки. Бюджеты есть, но все высвобождающиеся человеческие и управленческие ресурсы тут же направляются на основное направление, поскольку оно генерирует наиболее стабильный и полный денежный поток.

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

 

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

 

• Агентство Digital Bears ответило, что у них есть множество команд, идеально подходящих под его запрос, и предложило созвониться для уточнения требований и обсуждения условий.
• Сервисная компания Crazy Llamas мгновенно ответила, что их разработчики могут приступить завтра же, и тоже предложила скайп-колл.
• Компания Mighty Minds запросила ТЗ на оценку.
• Сервисная компания Hello World сообщила, что формирование команды под его запрос может занять от двух недель до двух месяцев, в зависимости от технических требований и желаемого процесса разработки. Да, скайп-колл поможет прояснить эти вопросы.
• Сервисная компания Lean Devs в ответном письме сообщила, что прежде, чем принять гипотезу Томаса за рабочий сценарий, они хотели бы сделать вместе с ним шаг назад, провести Customer Development, составить Lean Canvas и убедиться, что проблему надо решать именно таким образом. После чего можно будет приступать к проработке функциональных и нефункциональных требований, критериев приёмки, и постепенно двигаться к формулированию запроса на дизайн и разработку.
• Агентство Totally Right уведомило Томаса о том, что, согласно их внутренним процессам, команду разработки можно будет сформировать в течение месяца. И предложило проработать требования совместно с их Product Owner-ом, определиться с командой, необходимой для работы над проектом, выстроить Roadmap проекта, спрогнозировать сроки и стоимость работ.

 

Какие выводы сделал для себя Томас?

 

1. Он не будет работать с Digital Bears. Кого ему подсунут – большой вопрос, а само агентство, похоже, не особо переживает о конечном результате.
2. Crazy Llamas – это просто группа разработчиков, без понимания бизнесовой составляющей. В таком случае, они ничем не лучше фрилансеров на “удалёнку”.
3. Похоже, ребята из Mighty Minds мыслят категориями Waterfall. Томас слишком долго проработал в продуктовой разработке и понимает, что этот подход совсем не то что ему нужно. Процессы работы такого подрядчика будут слишком разными.
4. C Hello World не всё понятно. Могут оказаться интересными ребятами, а могут быть клоном Crazy Llamas. Надо пообщаться.
5. Lean Devs копают вопрос на полный штык и подходят к самой сути. Не понятно, правда, кто в итоге будет контролировать продукт – Томас или они, и как будут выстроены процессы и взаимоотношения. Но в этом определённо что-то есть.
6. Totally Right выглядят достаточно серьёзно, и предлагают вполне разумные вещи. С ними тоже имеет смысл пообщаться.

 

Нужен ли Agile в сервисном бизнесе?

Компания Томаса давно и прочно работает в парадигме Agile, постоянно совершенствуя свои процессы и пробуя на практике нововведения. Он понимает, что в команде, способной разработать полноценный продукт, должны быть как разработчики, так и Product Owner, отвечающий на вопрос “как именно наш продукт должен решать бизнес-цели?”, а также Scrum Master, отвечающего на вопрос “что ещё мы можем сделать, чтобы процесс разработки стал более эффективным?”

Поэтому Томасу не хочется работать с “просто разработчиками”, которые мыслят категориями “поставьте мне задачу – я её выполню”. Если у команды подрядчика отсутствует agile-подход и продуктовое мышление, весьма вероятно она будет делать не то что надо для развития продукта. И переламывать ситуацию придётся Томасу, влезая в процесс постановки, приоритизации, планирования и контроля выполнения задач с головой. Кто при этом будет думать о продукте, формулировать гипотезы, составлять критерии их успешности, мониторить результаты, собирать метрики и принимать решения – большой вопрос. У Томаса может элементарно не остаться времени для этого, поскольку он будет занят донесением бизнес-контекста до команды и микроменеджментом.

Поэтому ему не интересны ни агентства, предлагающие безымянные команды, ни команды, мыслящие категориями работы по ТЗ, ни команды, думающие только о процессе разработки. И тем более он не сможет работать с компанией, живущей в ритме Waterfall. Там, где Томас будет требовать быстрого вывода на рынок Minimal Marketable Feature, ему будут упорно бубнить про жизненный цикл разработки, диаграммы Гантта и длительный этап внедрения. А если даже и согласятся работать “по правилам этого идиота”, то результат будет предсказуемо плохим. В компании Томаса гибкие подходы закладывались с самого основания. При этом культура, позволяющая эффективно использовать все плюсы на полную катушку, сложилась только через год. Чего уж ожидать от команды, давно и плотно работающей в другой парадигме.

 

В заключение

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

Однако, если уже даже на сверхконсервативном уровне государства начинаются разговоры о проблемах традиционных подходов к управлению, то что уж говорить о крупном бизнесе. SAFe уверенно лидирует в чартах внедрения масштабируемого Agile в РФ. Думаю, не за горами тот час, когда работа по SAFe станет необходимым условием для начала любых переговоров о крупном контракте.

Ценности Agile 3.х. Когда я впервые познакомился с Agile… | by Сергей Гевлич | smysloteka

Когда я впервые познакомился с Agile манифестом, то с одной стороны, я восхитился ёмкостью и лаконичностью смысловой конструкции, с другой, задумался — что дальше? Или мы добрались до вершины мысли и лучше ничего не придумать. И вот на днях обнаружил Agile манифест 2.1 и в очередной раз восхитился красоте и логичности конструкции, но на этот раз удалось почувствовать логику в которой будет собран манифест 3.

х

Взгляните на смысловую конструкцию ценностей Agile:

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

Поскольку меня больше волнует именно конструкция, а не её содержание, я выделил жирным не ту часть, что слева от слова “важнее”, а само это слово. Это первый момент, который восхитил меня. Ценность кодируется через приоритезацию. Это очень круто! Поскольку данная конструкция становится практически применимой — она не просто что-то декларирует, но в любой непонятной ситуации позволяет делать выбор. Я писал об этом в заметке Как говорить о ценностях.

Второй момент, восхитивший меня — это часть конструкции справа. Да, да. Та, что как-бы отрицается. Точнее, мы можем так подумать, ведь она менее важна. Но последняя фраза манифеста всё ставит по местам:

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

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

Если вы ещё не видели манифест 2.1, то попробуйте подумать, что можно положить в его основу. Думаю, вы уже поняли, что сама конструкция не изменилась, но вопрос о том, что будет слева и справа от слова “важнее” остаётся открытым.

Красота решения кроется в том, что теперь справа в смысловой конструкции стоит то, что мы превозносили в манифесте 1.0

• Х1 важнее людей и взаимодействия
• Х2 важнее работающего продукта
• Х3 важнее сотрудничества с заказчиком
• Х4 важнее готовности к изменениям

Не знаю как вы, а я на этом месте испытал множественный интеллектуальный оргазм 🙂

Мы только что превозносили важность взаимопонимания, работающего продукта, сотрудничества с заказчиком, готовность к изменениям, а теперь отрицаем? Но что же мы ставим выше этих приоритетов?

Чтобы ответить на этот вопрос, можно обратиться к узким местам Agile. Многие восприняли этот манифест как отказ от стратегии. У кого-то это вызвало отторжение. Где-то внедрение Agile натолкнулось на сопротивление людей, ведь от них потребовалось принимать решения и брать ответственность. Но каковы основания для принятия решений? Прогибаться под заказчика, даже если он хочет того, что убьёт его продукт? И как поступать с идиотами? В общем, довольно много остаётся допущений.

Итак, давайте посмотрим, что кроется за нашими X1, X2, X3, X4.

• Командная работа и ответственность важнее людей и взаимодействия
• Бизнес-ценность важнее работающего продукта
• Построение партнёрства важнее сотрудничества с заказчиком
• Подготовка к изменениям важнее готовности к (реакции на) изменениям

Так и хочется добавить

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

Видите, получается многоэтажная конструкция:

• Командная работа и ответственность важнее людей и взаимодействия, что важнее процессов и инструментов
• Бизнес-ценность важнее работающего продукта, что важнее исчерпывающей документации
• Построение партнёрства важнее сотрудничества с заказчиком, что важнее согласования условий контракта
• Подготовка к изменениям важнее готовности к (реакции на) изменениям, что важнее следования первоначальному плану

Глядя на неё легко предсказать как будет выглядеть манифест 3. х

• Y1 важнее командной работы и ответственности
• Y2 важнее бизнес-ценности
• Y3 важнее построения партнёрства
• Y4 важнее подготовки к изменениям

Что скрывается за Y1, Y2, Y3, Y4? Пока не знаю, но возможно, удастся сделать предположения опираясь на модельку, которую недавно сконструировал Матрёшка смыслов, которая интегрирует в себя вложенность контекстов Роль / Сценарий / Сюжет / Миф.

Сделаю проекцию манифестов на модель матрёшки:

• Манифест 1 упразнил микроменеджмент и позволил командам заниматься самоорганизацией, опираясь на ценности, которые были декларированы с уровня Сценария для уровня Роль.
• Манифест 2 ответил на вопрос о стратегировании. Это декларации с уровня Сюжета на уровень Сценария.
• Можно предположить, что манифест 3 будет говорить на языке Мифа — это будет мировоззренческий манифест о картине мира.

Если у вас есть идеи, формулировок для третьего уровня Agile, пишите в комментариях.

AgileOne — RPO

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

Обещание We Are One™
Наш процесс начинается с подробного изучения целей и возможностей привлечения талантов в вашей компании.Помимо стандартных названий должностей, количества нанятых сотрудников и показателей времени заполнения, команда экспертов AgileOne углубляется в понимание ваших стратегий поиска и охвата, бренда занятости и существующего опыта кандидатов. Такой подход позволяет нашим командам по подбору персонала полностью интегрироваться в ваши внутренние процессы и корпоративную культуру. Короче говоря, ваши цели становятся нашими целями; ваш успех — это наш успех: Вместе мы едины™.

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

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

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

Talent Consulting Services
При принятии кадровых решений, определяющих развитие вашего бизнеса, доступ к экспертным знаниям может иметь решающее значение. Наши команды Talent Consulting Services предоставляют такие решения, как углубленный аудит привлечения талантов, оценки брендинга занятости и/или обзоры HR-технологий.Используя данные и отраслевые эталонные показатели, мы поможем вам понять ваше текущее состояние и разработать правильное решение для удовлетворения ваших новых потребностей.

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

Позвольте нам помочь вам принять лучшее решение о покупке для вашей организации. Наслаждайтесь пробным членством в онлайн-ресурсах без затрат на покупку полного членства, в том числе:
Аналитические отчеты с данными о вознаграждении и конкурентной рыночной информации
Данные о спросе и предложении по категориям вакансий, отраслям и географическим регионам
Списки поставщиков с более чем 2,8 миллионами кандидатов

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

Широкий спектр ресурсов
Легко добавляйте рекрутеров, координаторов по подбору персонала, специалистов по данным и отчетности или специалистов по найму маркетинга, чтобы ваша команда была готова к достижению своих целей.

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

Наша модель обслуживания Total Talent исходит из убеждения, что оптимальные таланты могут поступать из любой точки мира и выходят далеко за рамки традиционных хранилищ талантов. Фактически, «талант» представляет всех людей, работающих над формированием будущего вашей организации, включая постоянных и временных сотрудников, фрилансеров и стажеров.

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

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

Модель услуг Recruiting Marketing & Branding предоставляет вам инструменты и опыт для раскрытия вашего бренда в сфере занятости, позволяя вам привлекать кандидатов, которые соответствуют вашим приоритетам, ценностям и ожиданиям.

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

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

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

Безопасность | Стеклянная дверь

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

Veuillez терпеливейший кулон Que Nous vérifions Que Vous êtes une personne réelle.Votre contenu s’affichera bientôt. Si vous continuez à voir ce сообщение, связаться с нами по адресу Pour nous faire part du problème.

Bitte warten Sie, während wir überprüfen, dass Sie wirklich ein Mensch sind. Ихр Inhalt wird в Kürze angezeigt. Wenn Sie weiterhin diese Meldung erhalten, Информировать Sie uns darüber bitte по электронной почте и .

Эвен Гедульд А.У.Б. terwijl мы verifiëren u een человек согнуты. Uw содержание wordt бинненкорт вергегевен.Als u dit bericht blijft zien, stuur dan een электронная почта naar om ons te informeren по поводу ваших проблем.

Espera mientras verificamos Que eres una persona real. Tu contenido se sostrará кратко. Si continúas recibiendo este mensaje, информация о проблемах enviando электронная коррекция .

Espera mientras verificamos Que eres una persona real. Tu contenido aparecerá en краткий Si continúas viendo este mensaje, envía un correo electronico a пункт informarnos Que Tienes Problemas.

Aguarde enquanto confirmamos que você é uma pessoa de verdade. Сеу контеудо será exibido em breve. Caso continue recebendo esta mensagem, envie um e-mail para Para Nos Informar Sobre O Problema.

Attendi mentre verificiamo che sei una persona reale. Il tuo contenuto verra кратко визуализировать. Se continui a visualizzare questo message, invia удалить все сообщения по электронной почте indirizzo для информирования о проблеме.

Пожалуйста, включите Cookies и перезагрузите страницу.

Этот процесс выполняется автоматически. Вскоре ваш браузер перенаправит вас на запрошенный вами контент.

Подождите до 5 секунд…

Перенаправление…

Код: CF-102/6d836fe478aa3aa1

Agile в масштабе

Кратко

Амбиции

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

Проблемы

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

Решение

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

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

Естественно, руководители, которые сталкивались с agile-командами или слышали о них, задают несколько наводящих вопросов. Что, если компания запустит десятки, сотни или даже тысячи agile-команд по всей организации? Могут ли целые сегменты бизнеса научиться работать таким образом? Улучшит ли масштабирование agile корпоративную производительность так же, как agile-методы улучшат производительность отдельных команд?

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

Мы изучили масштабирование agile в сотнях компаний, включая небольшие фирмы, которые управляют всем предприятием с помощью agile-методов; более крупные компании, которые, как Spotify и Netflix, родились гибкими и стали более гибкими по мере своего роста; и компании, такие как Amazon и USAA (компания финансовых услуг для военного сообщества), совершают переход от традиционных иерархий к более гибким предприятиям.Наряду со многими историями успеха есть и разочарования. Например, попытки одной известной промышленной компании в течение последних пяти лет внедрять инновации в качестве бережливого стартапа еще не принесли финансовых результатов, к которым стремились активные инвесторы и совет директоров, а несколько руководителей высшего звена недавно ушли в отставку.

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

Лидировать в Agile, будучи Agile

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

Условия для agile-команд созрели в любой ситуации, когда проблемы сложны, решения поначалу неясны, требования к проекту могут измениться, возможно тесное сотрудничество с конечными пользователями, а творческие команды превзойдут группы управления и контроля. Рутинные операции, такие как техническое обслуживание, закупки и бухгалтерский учет, являются менее благодатной почвой. Agile-методы сначала прижились в ИТ-отделах и теперь широко используются в разработке программного обеспечения. Со временем они распространились на такие функции, как разработка продуктов, маркетинг и даже HR.(См. «Embracing Agile», HBR, май 2016 г., и «HR Goes Agile», HBR, март–апрель 2018 г.)

Эта статья также появляется в:

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

Когда лидеры сами не поняли и не приняли гибкие подходы, они могут попытаться масштабировать гибкие подходы так же, как они атаковали другие инициативы по изменениям: с помощью планов и директив сверху вниз. Послужной список лучше, когда они ведут себя как гибкая команда. Это означает рассматривать различные части организации как своих клиентов — людей и группы, чьи потребности различаются, вероятно, неправильно поняты и будут развиваться по мере распространения Agile.Исполнительная команда устанавливает приоритеты и упорядочивает возможности, чтобы улучшить качество обслуживания клиентов и повысить их успех. Руководители берутся за решение проблем и устраняют ограничения, а не делегируют эту работу подчиненным. В agile-лидерской команде, как и в любой другой agile-команде, есть «владелец инициативы», который отвечает за общие результаты, и фасилитатор, который тренирует членов команды и помогает поддерживать активное участие всех.

Bosch, ведущий мировой поставщик технологий и услуг с более чем 400 000 партнеров и филиалами в более чем 60 странах, применил этот подход.Когда руководители начали понимать, что традиционное управление «сверху вниз» более неэффективно в быстро меняющемся глобализированном мире, компания стала одной из первых применять гибкие методы. Но разные области бизнеса требовали разных подходов, и первая попытка Bosch внедрить то, что она назвала «двойной организацией» — такой, в которой горячие новые предприятия управлялись гибкими командами, а традиционные функции были исключены из действия, — поставила под угрозу цель целостной системы. трансформация. В 2015 году члены правления во главе с генеральным директором Фолькмаром Деннером решили разработать более единый подход к гибким командам.Правление выступило в качестве руководящего комитета и назначило Феликса Иероними, инженера-программиста, ставшего экспертом по agile, для руководства работой.

Сначала Иероними предполагал, что будет управлять заданием так же, как Bosch управлял большинством проектов: с целью, установленной датой завершения и регулярными отчетами о статусе для совета директоров. Но такой подход казался несовместимым с принципами Agile, и подразделения компании слишком скептически отнеслись к еще одной централизованно организованной программе. Таким образом, команда переключила передачи. «Руководящий комитет превратился в рабочий комитет, — сказал нам Иероними. «Обсуждения стали гораздо более интерактивными». Команда составила и ранжировала список корпоративных приоритетов, который регулярно обновлялся, и сосредоточилась на постоянном устранении общекорпоративных барьеров на пути к большей гибкости. Участники разошлись, чтобы вовлечь лидеров дивизий в диалог. «Стратегия превратилась из ежегодного проекта в непрерывный процесс, — говорит Иероними. «Члены правления разделились на небольшие agile-команды и протестировали различные подходы — некоторые с «владельцем продукта» и «agile-мастером» — для решения сложных проблем или работы над фундаментальными темами.Одна группа, например, разработала 10 новых принципов лидерства, выпущенных в 2016 году. Они лично испытали удовлетворение от увеличения скорости и эффективности. Вы не можете получить этот опыт, читая книгу». Сегодня Bosch работает как с гибкими командами, так и с традиционно структурированными подразделениями. Но в нем сообщается, что почти все области приняли ценности Agile, сотрудничают более эффективно и быстрее адаптируются к все более динамичным рынкам.

Переход на Agile Rolling

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

Эта статья также появляется в:

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

Создайте таксономию команд.

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

Таксономия бизнеса стоимостью 10 миллиардов долларов может выявить от 350 до 1000 или более потенциальных команд.Эти цифры звучат устрашающе, и руководители высшего звена часто не хотят даже думать о столь значительных изменениях («А что, если мы попробуем два или три из этих способов и посмотрим, что получится?»). Но ценность таксономии заключается в том, что она поощряет исследование трансформационного видения, разбивая путешествие на маленькие шаги, которые можно приостановить, повернуть или остановить в любое время. Это также помогает лидерам выявлять ограничения. После того, как вы определили команды, которые вы могли бы создать, и типы людей, которые вам потребуются, например, для их укомплектования, вам нужно спросить: есть ли у нас эти люди? Если да, то где они? Таксономия выявляет ваши пробелы в талантах и ​​людей, которых вы должны нанять или переобучить, чтобы заполнить их. Руководители также могут видеть, как каждая потенциальная команда вписывается в цель повышения качества обслуживания клиентов.

В

USAA работает более 500 agile-команд, и в 2018 году планируется добавить еще 100. Таксономия полностью видна всем на предприятии. «Если у вас нет действительно хорошей таксономии, вы получите избыточность и дублирование», — сказал нам главный операционный директор Карл Либерт. «Я хочу войти в аудиторию и спросить: «Кому принадлежит опыт смены адреса участника?» И мне нужен четкий и уверенный ответ от команды, которая владеет этим опытом, о том, звонит ли нам участник, входит ли он в нашу учетную запись. веб-сайт на ноутбуке или с помощью нашего мобильного приложения.Без указания пальцем. Нет ответов, начинающихся с «Это сложно».

Таксономия

USAA связывает деятельность agile-команд с людьми, ответственными за бизнес-подразделения и линейки продуктов. Цель состоит в том, чтобы убедиться, что менеджеры, ответственные за определенные части отчета о прибылях и убытках, понимают, как кросс-функциональные команды будут влиять на их результаты. В компании есть старшие руководители, которые действуют как генеральные менеджеры в каждом направлении бизнеса и несут полную ответственность за результаты бизнеса. Но эти лидеры полагаются на ориентированные на клиента кросс-организационные команды, чтобы выполнить большую часть работы.Компания также зависит от технологий и цифровых ресурсов, закрепленных за владельцами опыта; цель здесь состоит в том, чтобы убедиться, что бизнес-лидеры имеют сквозные ресурсы для достижения результатов, к которым они обязались. Цель таксономии — прояснить, как привлечь нужных людей к нужной работе, не создавая путаницы. Такая связь особенно важна, когда иерархическая организационная структура не соответствует поведению клиентов. Например, многие компании имеют отдельные структуры и отчеты о прибылях и убытках для онлайн- и офлайн-операций, но клиенты хотят бесшовно интегрированного многоканального взаимодействия.Четкая таксономия, которая запускает правильные кросс-организационные команды, делает возможным такое согласование.

Последовательность перехода.

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

Несколько компаний, столкнувшихся со стратегическими угрозами и нуждающихся в радикальных изменениях, приступили к крупномасштабному развертыванию системы «все сразу» в некоторых подразделениях. Например, в 2015 году ING Netherlands прогнозировала рост потребительского спроса на цифровые решения и усиление вторжений новых цифровых конкурентов («финтех-компаний»). Руководство решило действовать агрессивно.Он упразднил организационные структуры своих самых инновационных функций, включая разработку ИТ, управление продуктами, управление каналами сбыта и маркетинг, по сути упразднив работу каждого. Затем были созданы небольшие гибкие «отряды», и потребовалось почти 3500 сотрудников, чтобы повторно подать заявку на 2500 измененных вакансий в этих отрядах. Около 40% людей, занимающих эти должности, должны были освоить новую работу, и всем пришлось коренным образом изменить свое мышление. (См. «Командный эксперимент One Bank’s Agile», HBR, март–апрель 2018 г.)

Но переходы большого взрыва сложны. Они требуют полной приверженности руководства, восприимчивой культуры, достаточного количества талантливых и опытных agile-практиков, чтобы укомплектовать сотни команд, не истощая другие возможности, и строго предписывающих инструкций, чтобы согласовать подход каждого. Они также требуют высокой терпимости к риску, наряду с планами на случай непредвиденных обстоятельств. ING продолжает сглаживать недостатки по мере того, как она гибко расширяется по всей организации.

Компаниям, которым не хватает этих активов, лучше внедрить Agile поэтапно, чтобы каждое подразделение соответствовало реализации возможностей своим возможностям.В начале своей agile-инициативы группа передовых технологий в 3M Health Information Systems запускала от восьми до десяти команд каждый месяц или два; сейчас, два года спустя, работает более 90 команд. Лаборатория корпоративных исследовательских систем 3M открылась позже, но уже через три месяца набрала 20 команд.

Переходы Большого взрыва сложны. Возможно, будет лучше развертывать Agile поэтапно.

Каким бы ни был темп или конечная точка, результаты должны начать появляться быстро. Финансовые результаты могут занять некоторое время — Джефф Безос считает, что большинству инициатив требуется от пяти до семи лет, чтобы принести дивиденды Amazon, — но положительные изменения в поведении клиентов и решении командных проблем являются ранними признаками того, что инициативы находятся на правильном пути. «Внедрение Agile уже позволило ускорить доставку продуктов и выпустить бета-версию приложения на шесть месяцев раньше, чем первоначально планировалось», — говорит Тэмми Спэрроу, старший менеджер программы в 3M Health Information Systems.

Руководители подразделений

могут определять последовательность действий так же, как и любая agile-группа. Начните с инициатив, которые потенциально могут принести наибольшую пользу и дать больше всего информации. SAP, компания-разработчик корпоративного программного обеспечения, была одним из первых масштабаторов agile, запустив этот процесс десять лет назад.Руководители сначала расширили agile-подходы в своих подразделениях по разработке программного обеспечения — сегменте, в высшей степени ориентированном на клиента, где они могли тестировать и совершенствовать подход. Они создали небольшую консультационную группу для обучения, коучинга и внедрения нового метода работы, а также создали средство отслеживания результатов, чтобы каждый мог видеть достижения команд. «Демонстрация конкретных примеров впечатляющего повышения производительности благодаря Agile создавала все большую и большую привлекательность для организации», — говорит Себастьян Вагнер, который в то время был менеджером-консультантом в этой группе.В течение следующих двух лет компания внедрила Agile более чем в 80% своих организаций разработчиков, создав более 2000 команд. Специалисты по продажам и маркетингу увидели необходимость адаптироваться, чтобы идти в ногу со временем, поэтому эти области пошли дальше. После того, как клиентская часть бизнеса начала двигаться со скоростью, пришло время сделать скачок для серверной части, поэтому SAP перевела свою группу, работающую над внутренними ИТ-системами, на гибкую.

Слишком многие компании совершают ошибку, стремясь к легким победам. Они помещают команды в удаленные инкубаторы.Они вмешиваются, чтобы создать простые обходные пути для системных препятствий. Такая забота увеличивает шансы команды на успех, но не создает обучающей среды или организационных изменений, необходимых для масштабирования десятков или сотен команд. Первые agile-команды компании несут бремя судьбы. Их тестирование, как и тестирование любого прототипа, должно отражать различные реалистичные условия. Как и SAP, самые успешные компании сосредотачиваются на жизненно важном опыте работы с клиентами, который вызывает наибольшее разочарование среди функциональных разрозненных структур.

Тем не менее ни одна agile-команда не должна запускаться до тех пор, пока она не будет готова к работе. Готовность не означает детальное планирование и гарантированный успех. Это означает, что команда:

1. сосредоточены на крупных деловых возможностях, на карту поставлено много
2. отвечает за конкретные результаты
3. доверено работать автономно — руководствуясь четкими правами на принятие решений, надлежащими ресурсами и укомплектованным небольшой группой многопрофильных экспертов, которые увлечены возможностью
4. стремится применять agile-ценности, принципы и практики
5. уполномочен тесно сотрудничать с клиентами
6. способность создавать быстрые прототипы и быстрые петли обратной связи
7. при поддержке высшего руководства, которое устраняет препятствия и способствует принятию работы команды

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

Осваивайте крупномасштабные agile-инициативы.

Многим руководителям сложно представить, что небольшие agile-команды могут атаковать крупномасштабные долгосрочные проекты. Но в принципе нет ограничений на количество Agile-команд, которые вы можете создать, или на размер инициативы. Вы можете создавать «команды команд», которые работают над связанными инициативами — подход, который легко масштабируется. Например, в авиационном бизнесе Saab более 100 гибких команд работают над программным обеспечением, аппаратным обеспечением и фюзеляжем истребителя Gripen — изделия стоимостью 43 миллиона долларов, которое, безусловно, является одним из самых сложных продуктов в мире.Он координирует ежедневные стендапы команд. В 7:30 каждая передовая agile-команда проводит 15-минутное совещание, чтобы отметить препятствия, некоторые из которых не могут быть устранены внутри этой команды. В 7:45 препятствия, требующие координации, передаются группе команд, где лидеры работают над урегулированием или дальнейшей эскалацией проблем. Этот подход сохраняется, и к 8:45 исполнительная команда имеет список критических проблем, которые она должна решить, чтобы не отставать от прогресса. Aeronautics также координирует свои команды с помощью общего ритма трехнедельных спринтов, генерального плана проекта, который рассматривается как живой документ, и совместного размещения традиционно разрозненных частей организации — например, размещение пилотов-испытателей и симуляторов с командами разработчиков.Результаты впечатляют: компания IHS Jane’s признала Gripen самым экономичным военным самолетом в мире.

Руководящие группы должны внедрить ценности Agile на уровне всего предприятия.

Повышение гибкости в бизнесе

Расширение числа agile-команд — важный шаг к повышению гибкости бизнеса. Но не менее важно то, как эти команды взаимодействуют с остальной частью организации. Даже самые продвинутые agile-предприятия — Amazon, Spotify, Google, Netflix, Bosch, Saab, SAP, Salesforce, Riot Games, Tesla и SpaceX и многие другие — используют сочетание agile-команд и традиционных структур. Чтобы гарантировать, что бюрократические функции не мешают работе agile-команд и не препятствуют внедрению и коммерциализации инноваций, разработанных этими командами, такие компании постоянно настаивают на больших изменениях как минимум в четырех областях.

Ценности и принципы.

Традиционная иерархическая компания обычно может вместить небольшое количество agile-команд, разбросанных по организации. Конфликты между командами и обычными процедурами могут быть разрешены путем личного вмешательства и обходных путей.Однако, когда компания запускает несколько сотен agile-команд, такое специальное приспособление становится невозможным. Agile-команды будут продвигаться вперед на всех фронтах. Традиционно структурированные части организации будут яростно защищать статус-кво. Как и в случае с любыми изменениями, скептики могут и будут вырабатывать всевозможные антитела, атакующие agile, начиная от отказа работать по agile-графику («Извините, мы не можем получить нужный вам программный модуль в течение шести месяцев») до отказа средств от больших возможностей, которые требуют незнакомых решений.

Таким образом, руководящая группа, надеющаяся масштабировать agile, должна привить agile-ценности и принципы всему предприятию, включая те его части, которые не объединяются в agile-команды. Вот почему руководители Bosch разработали новые принципы лидерства и распространили их по всей компании: они хотели, чтобы все понимали, что все будет по-другому и что Agile будет в центре корпоративной культуры.

Операционные архитектуры.

Внедрение agile в масштабе требует модульности, а затем бесшовной интеграции рабочих потоков.Например, Amazon может развертывать программное обеспечение тысячи раз в день, потому что его ИТ-архитектура была разработана, чтобы помочь разработчикам делать быстрые и частые выпуски, не ставя под угрозу сложные системы фирмы. Но многие крупные компании, как бы быстро они ни писали программы, могут развертывать ПО всего несколько раз в день или в неделю; так работает их архитектура.

Опираясь на модульный подход к разработке продуктов, впервые предложенный Toyota, Tesla тщательно проектирует интерфейсы между компонентами своих автомобилей, чтобы каждый модуль мог внедрять инновации независимо. Таким образом, команда разработчиков бамперов может изменить что угодно, пока поддерживает стабильные интерфейсы с частями, на которые она влияет. Tesla также отказывается от традиционных ежегодных циклов выпуска в пользу ответов в режиме реального времени на отзывы клиентов. Генеральный директор Илон Маск говорит, что компания вносит около 20 технических изменений в неделю, чтобы улучшить производство и производительность Model S. Примеры включают новые аккумуляторные батареи, обновленное оборудование безопасности и автопилота, а также программное обеспечение, которое автоматически регулирует рулевое колесо и сиденье для облегчения посадки. и выход.

В самых передовых agile-предприятиях инновационные архитектуры продуктов и процессов преодолевают некоторые из самых сложных организационных ограничений на пути дальнейшего масштабирования. Riot Games, разработчик чрезвычайно успешной многопользовательской онлайновой боевой арены League of Legends, перерабатывает интерфейсы между гибкими командами и функции поддержки и контроля, которые работают традиционно, такие как объекты, финансы и управление персоналом. Брэндон Хсиунг, руководитель этой продолжающейся инициативы, говорит, что она включает как минимум два ключевых этапа.Один из них — изменение определения функций своих клиентов. «Их клиенты — это не их функциональные начальники, или генеральный директор, или даже совет директоров», — объясняет он. «Их клиенты — это команды разработчиков, которым они обслуживают, и которые в конечном итоге обслуживают наших игроков». Компания ввела опросы Net Promoter, чтобы собрать отзывы о том, будут ли эти клиенты рекомендовать функции другим, и дала понять, что недовольные клиенты могут иногда нанимать сторонних поставщиков. «Это последнее, чего мы хотим, но мы хотим, чтобы наши функции развивали возможности мирового класса, которые могли бы конкурировать на свободном рынке», — говорит Сюн.

Riot Games также изменила способ взаимодействия своих корпоративных функций с agile-командами. Некоторые члены корпоративных функций могут быть встроены в agile-команды, или часть возможностей функции может быть выделена для запросов от agile-команд. В качестве альтернативы функции могут иметь мало формального взаимодействия с командами после сотрудничества с ними для установления определенных границ. Сюн говорит: «Такие организации, как недвижимость, обучение и развитие, могут публиковать философию, рекомендации и правила, а затем говорить: «Вот наши рекомендации.Пока вы действуете внутри них, вы можете сойти с ума; делайте все, что, по вашему мнению, лучше для наших игроков».

В компаниях, которые расширили масштабы agile, организационные схемы вспомогательных функций и рутинных операций в целом выглядят почти так же, как и раньше, хотя часто с меньшим количеством уровней управления и более широким диапазоном контроля, поскольку руководители учатся доверять людям и расширять их возможности. Большие изменения коснулись способов работы функциональных отделов. Функциональные приоритеты обязательно более полно согласуются с корпоративными стратегиями.Если одним из ключевых приоритетов компании является улучшение мобильного опыта клиентов, это не может быть номером 15 в списке финансирования или списке найма отдела кадров. А таким отделам, как юридический, может потребоваться буферная емкость для обработки срочных запросов от высокоприоритетных agile-команд.

Со временем даже рутинные операции с иерархическими структурами, вероятно, разовьют более гибкое мышление. Конечно, финансовые отделы всегда будут управлять бюджетами, но им не нужно постоянно подвергать сомнению решения владельцев agile-инициатив.«Наш финансовый директор постоянно перекладывает ответственность на наделенные полномочиями agile-команды, — говорит Ахмед Сидки, глава отдела управления развитием в Riot Games. «Он скажет: «Я здесь не для того, чтобы управлять финансами компании. Вы, как лидеры команды. Я здесь в качестве консультанта». В повседневной организации финансовые партнеры входят в состав каждой команды. Они не контролируют то, что делают или не делают команды. Они больше похожи на тренеров по финансам, которые задают трудные вопросы и делятся глубокими знаниями. Но в конечном счете решения принимает лидер команды, исходя из того, что лучше для игроков Riot.

Некоторым компаниям и отдельным лицам эти компромиссы могут быть трудно принять и реализовать. Ослабление контроля всегда пугает, пока вы не сделаете это и не обнаружите, что люди стали счастливее, а показатели успеха утроились. В недавнем опросе Bain, в котором приняли участие почти 1300 руководителей по всему миру, с этим утверждением об управлении согласилось больше респондентов, чем с любым другим: «Сегодняшние бизнес-лидеры должны доверять людям и наделять их полномочиями, а не командовать ими и контролировать их». (Только 5% не согласились.)

Приобретение талантов и мотивация.

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

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

Ежегодные циклы планирования и составления бюджета.

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

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

ЗАКЛЮЧЕНИЕ

Компании, которые успешно масштабируют agile, наблюдают серьезные изменения в своем бизнесе. Масштабирование меняет структуру работы, так что бизнес делает больше инноваций по сравнению с рутинными операциями. Бизнес способен лучше понимать меняющиеся условия и приоритеты, разрабатывать адаптивные решения и избегать постоянных кризисов, которые так часто поражают традиционные иерархии.Подрывные инновации станут менее разрушительными и будут больше походить на обычный адаптивный бизнес. Масштабирование также привносит ценности и принципы гибкости в бизнес-операции и функции поддержки, даже если многие рутинные действия остаются. Это приводит к повышению эффективности и производительности в некоторых крупных центрах затрат бизнеса. Он улучшает операционную архитектуру и организационные модели для улучшения координации между гибкими командами и рутинными операциями. Изменения вступают в силу быстрее и лучше реагируют на потребности клиентов.Наконец, бизнес обеспечивает ощутимые улучшения результатов — не только лучшие финансовые результаты, но и большую лояльность клиентов и вовлеченность сотрудников.

Подход Agile «тестируй и учись» часто описывается как инкрементный и итеративный, но никто не должен путать инкрементальные процессы разработки с инкрементным мышлением. SpaceX, например, стремится использовать гибкие инновации, чтобы начать доставку людей на Марс к 2024 году с целью создания на планете самодостаточной колонии.Как это произойдет? Ну, люди в компании на самом деле не знают… пока. Но у них есть видение, что это возможно, и у них в голове есть несколько шагов. Они намерены значительно повысить надежность и сократить расходы, отчасти за счет повторного использования ракет так же, как самолетов. Они намерены усовершенствовать двигательные установки для запуска ракет, способных перевозить не менее 100 человек. Они планируют выяснить, как дозаправляться в космосе. Некоторые из шагов включают максимально возможное продвижение существующих технологий, а затем ожидание появления новых партнеров и новых технологий.

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

Версия этой статьи появилась в выпуске Harvard Business Review за май – июнь 2018 г. (стр. 88–96) .

Совещание 1:1 — лучшая тактика Agile-управления эффективностью

Совещание 1:1 — лучшая тактика Agile-управления эффективностью для непрерывной и эффективной обратной связи

Одним из столпов Agile Performance Management является постоянная и эффективная обратная связь.Тем не менее, это широкая стратегия.

Что это значит и как компания инициирует стратегию «непрерывной эффективной обратной связи» ?

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

«Регулярно запланированные встречи один на один — самый ценный инструмент для любого, кто руководит командой». – Майк из ManagerTools.com

5 причин, почему встречи один на один являются лучшей тактикой гибкого управления эффективностью

1. Бесспорно, это лучший способ построить настоящие отношения с каждым непосредственным подчиненным. Улучшение отношений с вашими непосредственными подчиненными дает лучшие результаты. Лучший способ систематически строить свои профессиональные отношения — проводить встречи один на один еженедельно, раз в две недели или ежемесячно.Прочтите некоторые из наших любимых статей из Harvard Business Review ниже, если вы не согласны.

2. Их уже делают менеджеры! Или должно быть. Если вы спросите менеджера, проводят ли они встречи 1:1 со своими непосредственными подчиненными, и он ответит «нет», как еще они смогут построить настоящие, подлинные отношения со своими непосредственными подчиненными.

3. Это вневременная практика управления.  Это не новость. Насколько это здорово? Это не новый виджет или сеанс гуру. Он испечен в соответствии с проверенной передовой практикой.Самым большим преимуществом генерального директора или специалиста по кадрам при реализации непрерывной и эффективной стратегии обратной связи является то, что встречи один на один являются основным продуктом и стандартом для отличных менеджеров и компаний. Это видео для Bowen Engineering о встречах 1 : 1 чистое.

4. Менеджер наделен полномочиями. Есть причина, по которой менеджеры являются менеджерами: они зарекомендовали себя как лидеры и заслужили ответственность компании (и других лидеров) за руководство командой. Повторное подчеркивание важности ведения переговоров один на один со своими руководителями оказывает на них давление и позволяет доверять им лидерство в своем уникальном стиле.

5. Ведение заметок и документирование, скорее всего, уже происходит. Опросите своих менеджеров и спросите их, как они делают заметки во время встреч один на один. Поскольку менеджеры, которые их выполняют (а они все должны), скорее всего, документируют их в Microsoft Word, Evernote, Google Docs и старом добром ручке и бумаге. Ваша платформа Agile Performance Management должна автоматизировать многие ручные функции, необходимые для хорошей встречи 1:1.

Мы не одиноки в своем убеждении в силе встреч один на один.Прочтите статью в Harvard Business Reviews о том, как использовать их для повышения продуктивности сотрудников, о затратах на отмену встреч один на один или о том, что делает каждый хороший менеджер.

Лучшая стратегия гибкого управления эффективностью — обеспечить эффективную связь и обратную связь между менеджером и непосредственным подчиненным. Нет лучшей тактики Agile Performance Management, чем вневременная передовая практика проведения регулярных, запланированных и документированных встреч один на один с каждым непосредственным подчиненным.

 

Agile встречает разнообразие, справедливость и инклюзивность

На этом занятии мы исследуем, как столпы Scrum могут помочь нам в создании большего разнообразия, справедливости и инклюзивности (DEI) в организациях.На первой сессии этой серии из двух частей мы сосредоточимся на бизнес-обосновании интеграции практик DEI и обсудим, как Три столпа Scrum: прозрачность, проверка и адаптация могут помочь нам в создании большего количества DEI в agile-командах. и по всей организации. Памела Мейер, доктор философии. проводит сеанс с участием группы лидеров мнений, которые поделятся своим опытом, знаниями и рекомендациями. Мы изучаем, как agile-команды могут быть моделями для DEI, и стремимся выяснить, как мы можем воплотить добрые намерения в лучшие бизнес-практики и рабочий опыт, чтобы каждый мог использовать преимущества agility и помочь изменить мир труда. Зрители узнают: • Почему улучшение DEI помогает повысить производительность команды и улучшить бизнес-результаты • Как фундаментальные ценности Scrum совпадают с ценностями DEI • Как привилегии и неосознанные предубеждения могут препятствовать работе команды • Лучшие практики и стратегии, которые внедряют agile-эксперты и специалисты DEI Этот сеанс действителен для 2 SEU.

Памела Мейер, доктор философии.

Д-р Памела Мейер является автором четырех книг по гибкости, инновациям и обучению, в том числе «Смена гибкости: создание гибких и эффективных лидеров, команд и организаций», а также сертифицированным скрам-мастером®.Благодаря своим глубоким исследованиям и опыту в понимании того, как взрослые учатся инновациям и импровизации, а также двадцатилетнему опыту работы с компаниями из списка Fortune от 50 до 500, Мейер помогает бизнес-лидерам внедрять передовые методы гибкости для достижения результатов. Помимо работы с организациями, Памела Мейер преподает курсы по бизнес-инновациям, организационным изменениям и обучению взрослых в Университете ДеПола в Чикаго.

Мелани Коффи

Мелани Коффи — эксперт по коммуникациям с более чем 20-летним опытом работы в журналистике.Благодаря эффективному рассказыванию историй и созданию сообщества она помогает брендам повысить осведомленность о продукте или услуге, чтобы повысить ценность продукта или услуги, а также помогает организациям поднять глобальную дискуссию по ключевым социальным проблемам. Мелани, которая давно выступает за разнообразие, справедливость и инклюзивность, провела множество обучающих семинаров по инклюзивному лидерству, разнообразию и эффективной коммуникации для профессионалов из различных отраслей, включая юриспруденцию, средства массовой информации и технологии. Ее естественное любопытство и страсть к совместным, эффективным изменениям привели ее в мир Agile 10 лет назад, где она является сертифицированным мастером Scrum, который постоянно учится и оттачивает свое мастерство, поскольку никогда не становится лучше.

Трентон Меридет старший

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

Тодд Уильямс

Тодд Уильямс — ведущий специалист программы стратегического планирования, Agile и бизнес-лидер: проверенный агент изменений и создатель консенсуса, проводящий Agile-преобразования, в том числе четыре бизнес-преобразования крупных предприятий: Bank of America Conversational Commerce «Erica», AT&T Intergraded Cloud Computing (AIC), T- Mobile Billing and McKesson Technology Group (Scaled Agile Transformation & Global Agile PMO). Тодд более 15 лет успешно руководил комплексными, высокоэффективными корпоративными программами, трансформацией бизнеса и ИТ-программами в национальных и глобальных средах. Он заработал свою репутацию, эффективно работая на предприятии в качестве консультанта, руководителя программ, руководителя операций и отдельных участников, ведущих корпоративные инициативы, обеспечивающие рост доходов и прибыли, а также общую эффективность предприятия. Он имеет степень магистра наук в области вычислительной техники Университета ДеПола; Консультант программы SAFe 5 (SPC5), PMP, сертифицированный Scrum Professional, SAFe RTE, черный пояс по методу Lean Six Sigma.

Джил Фелисиано

Джил Фелисиано — директор по многообразию и инклюзивности, привлечению талантов в Advocate Aurora Health, имеет опыт подготовки компаний к будущему работы в области управления персоналом, операционной инженерии, образования и инструктажа по организационной инклюзивности.Jyl имеет 10-летний опыт в обновлении и совершенствовании операционных моделей D&I путем разработки справедливых стратегий поиска, отбора и удержания с акцентом на обучение лидеров руководству с инклюзивной линзой и внедрению инновационных тактик, основанных на анализе рыночных данных, для успешной интеграции. справедливость и участие в каждой фазе жизненного цикла сотрудника. Джил успешно руководила Глобальными программами интеграции в финансовой, технологической и потребительской отраслях, призывая лидеров выйти за рамки диалога и перейти к действиям по вопросам разнообразия, власти, привилегий и лидерства.

Сертификация

Professional Agile Leadership™ | Scrum.org

Подтвердите свои знания профессионального лидерства Agile

Тест Professional Agile Leadership ^TM (PAL I) доступен для всех, кто желает подтвердить, что вы являетесь лидером, который понимает, что Agile повышает ценность вашего бизнеса, и почему понимание лидерства, спонсорство и поддержка Agile-практик важны. необходимо для того, чтобы организация стала более гибкой.Те, кто проходит, получают признанный в отрасли сертификат PAL I от Scrum.org; демонстрация фундаментального уровня понимания того, как гибкость повышает ценность организации, почему поддержка руководства agile-команд необходима для достижения организационной гибкости и что лидеры могут сделать, чтобы поддержать свои команды, чтобы помочь им достичь более высокой производительности.

Хотя посещение курса не является обязательным условием, настоятельно рекомендуется посетить курс Professional Agile Leadership Essentials (PAL-E).Если вы чувствуете, что уже обладаете высоким уровнем навыков гибкого лидерства, а также хорошо понимаете Scrum, вы можете пройти тест PAL I. Эта оценка бросит вызов вашему мышлению; если вы не работаете с мышлением лидера-слуги и не готовы оказывать высокий уровень доверия в руки тех, кого вы возглавляете, вам, вероятно, будет трудно пройти тест PAL I. Оценка охватывает темы, охватывающие 14 основных областей, определенных в компетенции Professional Scrum. Список основных областей, охваченных этой оценкой, доступен на странице «Рекомендуемая литература».

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

Подготовка к оценке

Чтобы подготовиться, мы рекомендуем вам прочитать этот блог о ценностях Scrum, написанный Gunther Verheyen, прочитать руководство по Scrum и просмотреть материалы, перечисленные на странице «Рекомендуемая литература» и в Пути обучения Agile-лидеров.

Перевод оценки

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

Приспособления для лиц с физическими или умственными недостатками

Мы очень серьезно относимся к этим соображениям и рассматриваем каждый случай индивидуально. Пожалуйста, свяжитесь [email protected] в отношении ваших обстоятельств, и мы можем посоветовать вам, что делать дальше.

Другая информация

Найдите список существующих обладателей сертификатов Professional Scrum здесь или просмотрите разбивку по количеству людей, имеющих сертификаты.

Стоимость PAL I составляет 200 долларов США. Пароли оценки не имеют срока действия и остаются действительными до тех пор, пока не будут использованы. Подробнее см. ниже.

Раннее и непрерывное предоставление ценности

В следующих трех постах мы обсудим принципы Agile и способы их применения при разработке оборудования. В этом посте мы рассмотрим обеспечение постоянной ценности.

Как компания-разработчик программного обеспечения, наши процессы разработки основаны на многих передовых методах Agile.Чтобы было ясно, я думаю, что Agile отлично подходит для разработки программного обеспечения. Особенно, когда мы включаем в понятие Agile множество улучшений, которые были добавлены за эти годы, такие как Kanban и Definition of Done.

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

Принципы Agile, адаптированные для аппаратного обеспечения

Из-за явного присутствия программного обеспечения в Agile-принципах я предложил альтернативную формулировку для нашего взгляда на их применение в разработке аппаратного обеспечения. Я заменил слово «программное обеспечение» на «продукты» и «разработчики» на «инженеры» .

1. Наивысшим приоритетом для нас является удовлетворение клиента за счет своевременной и непрерывной поставки ценных продуктов .
2. Приветствуйте изменяющиеся требования, даже на поздних стадиях разработки.Гибкие процессы используют изменения для конкурентного преимущества клиента.
3. Доставляйте работающие продукты часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
4. Деловые люди и инженеры должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
6. Наиболее эффективным и действенным методом передачи информации команде инженеров и внутри нее является беседа лицом к лицу.
7. Рабочий продукт является основным показателем прогресса.
8. Гибкие процессы способствуют устойчивому развитию. Спонсоры, инженеры и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного времени.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота — искусство максимизировать объем незавершенной работы — имеет важное значение.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Давайте рассмотрим каждый из них, начиная сверху.

Принцип Agile 1. Нашим наивысшим приоритетом является удовлетворение клиента за счет своевременной и непрерывной поставки ценного продукта.

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

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

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

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

Хотите узнать больше о принципах Lean-Agile? Ознакомьтесь с нашими бесплатными курсами Lean-Agile в Академии Playbook, такими как «Планирование набегающей волны», «Применение Agile к оборудованию» и «Управление проектами критической цепи».

Даже среди самых передовых компаний по разработке продуктов непрерывная поставка редко оказывается наиболее прибыльным вариантом. Например, за четыре года продаж iPad было всего пять разных моделей, хотя операционная система подвергалась более частым обновлениям. Ежегодно Toyota выпускает новые модели.

Каковы основные причины, по которым менее частые выпуски становятся более прибыльными?

Какова стоимость изменений в разработке оборудования?

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

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

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

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

Аппаратные средства тесно интегрированы в природу

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

Команды аппаратного обеспечения еще не решили проблему модульности из-за сил, которые отталкивают нас от повышения модульности. Повышение модульности обычно увеличивает нашу стоимость проданных товаров (COGS) и снижает производительность системы, включая часто важные вес и размер нашего продукта. Эти силы сводят на нет преимущества модульности и снова подталкивают нас к более дорогостоящим изменениям.

Мы подробнее обсудим модульность в следующем посте, но суть в том, что стоимость изменений в оборудовании обычно намного выше, чем в программном обеспечении.Чем выше наша стоимость изменений, тем больше времени требуется для ее возмещения и тем дольше период окупаемости каждого нового изменения и выпуска. Одного этого достаточно, чтобы увеличить оптимальную скорость высвобождения. Но это еще не все…

Стоимость компонентов (COGS) обычно составляет 30% дохода от продукта

COGS аппаратных продуктов обычно потребляют не менее 30% нашего дохода от продуктов (не включая капитальные затраты на инструменты). В большинстве компаний этот процент значительно выше. С увеличением себестоимости уменьшается прибыль с каждой единицы.Мы должны продать больше единиц, чтобы оплатить стоимость разработки и изменения. Это еще больше удлиняет период окупаемости и наш оптимальный цикл выпуска.

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

Оптимальный цикл выпуска аппаратного обеспечения

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

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

В железе стоимость модульности выше, а остальные затраты все же присутствуют, так что это выглядит примерно так:

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

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

Принципы Agile, адаптированные для разработки аппаратного обеспечения

Я бы предложил альтернативу первому принципу, который устанавливает (почти) такое же большое преимущество в аппаратном обеспечении, как частые выпуски клиентов в Agile.

Альтернативой для разработки аппаратного обеспечения может быть:

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

Наивысшим приоритетом для нас является удовлетворение потребностей клиентов за счет своевременной непрерывной доставки ценности .

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

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

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

Когда мы стремимся к непрерывной доставке ценности, мы учимся разделять наши процессы разработки. Мы разделяем наше обучение на более частые и обширные проверки, и мы разделяем наши Фазовые Врата на более индивидуальные основные вехи. Чем более непрерывным (разрозненным) является наше снижение рисков, тем быстрее будет работать система разработки продукта, и тем раньше и выгоднее будет наш окончательный выпуск продукта.

Примечание из моей мыльницы

Некоторые люди считают диаграммы Ганта индикатором порочного непостоянного водопадного процесса, который считается антитезой Agile.Однако не диаграмма Ганта является злом. Дело в том, что с традиционными инструментами управления проектами мы вынуждены строить планы, которыми может управлять один человек. Даже тогда трудно изменить планы.

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

В части 4 мы углубимся во второй принцип Agile: приветствуем изменения требований. Там мы обнаруживаем явные различия между разработкой аппаратного и программного обеспечения, которые требуют изменения нашего подхода для максимизации нашей прибыли.

——

Загрузите электронную книгу «Применение Agile к оборудованию», чтобы получить всю серию в виде документа, которым можно поделиться.

Связанные статьи

Гибкая разработка
Применение ценностей Agile к разработке аппаратного обеспечения
Принцип Agile 1: Раннее и непрерывное предоставление ценности
Принцип Agile 2: Принятие изменяющихся требований
Создание более гибкой разработки аппаратного обеспечения
Раннее обучение разработке аппаратного обеспечения
Руководство по применению Agile при разработке аппаратного обеспечения
Руководство по Канбану

.

No related posts.