Agile принцип: Основополагающие принципы Agile-манифеста

Agile-маркетинг. Принципы и подход — Маркетинг на vc.ru

Методология Agile, зародившись в начале 70-х годов как комплекс гибких методов разработки программного обеспечения, получила широкое распространение в управлении проектами в разных сферах бизнеса.

2958 просмотров

Основной смысл Agile-практик сосредоточен в манифесте гибкой разработки ПО (Agile Manifesto), который ставит в приоритет:

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

Манифест Agile был сформулирован в феврале 2001 года инициативной группой из 17 программистов, назвавших себя Agile Alliance. Это время считается началом повсеместного распространения гибкой методологии как практики управления проектами и организации бизнес-процессов не только в области разработки, но и в других областях, среди которых и маркетинг.

Зачем маркетингу Agile

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

То же самое сегодня актуально и для маркетинга, в котором успех рекламной кампании зависит от скорости реагирования на изменения в digital-среде и оригинальности решений.

Сегодня в любом клиентском сегменте этой сферы можно наблюдать следующую картину:

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

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

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

Принципы Agile-маркетинга

По примеру программистов и их Agile Manifesto группа маркетологов выработала и сформулировала манифест agile-маркетинга. Окончательный вариант был представлен и согласован с широким кругом специалистов на конференции SprintZero: The Physics of Agile Marketing.

Данный манифест провозглашает:

1. Анализ вместо мнений и условностей. Цикличная и постоянная работа, предполагающая изучение клиента, внесение изменений в текущую работу и оценку результатов. Никаких условностей, практик и мнения от топ-менеджмента, если анализ не выявил пользы.
2. Ориентированность на клиента, а не на внутреннюю иерархию и соперничество между отделами. В Agile на первом месте интересы и потребности клиента.
3. Небольшие адаптивные кампании вместо масштабных и сложных. Классические маркетинговые стратегии плохо поддаются оперативной корректировке. В Agile кампании делятся на несколько кратких циклов, после каждого проводится анализ и при выявлении проблем вносятся изменения.
4. Изучение аудитории вместо прогнозирования. В классическом маркетинге исследование ЦА проводят, как правило, раз в год. За этот период привычки и мнения аудитории могут поменяться несколько раз, а это значит, что ориентированные на нее кампании могут оказаться неэффективными. Agile-подход предполагает постоянное проведение исследований ЦА с тем, чтобы при необходимости максимально быстро переориентировать рекламную кампанию.
5. Приоритет гибкого планирования перед жестким. Планирование в Agile остается, но без жесткой привязки к изначальному видению. С каждым новым циклом (итерацией) в план вносятся корректировки.
6. Оперативная реакция на изменения. Например, если появляется новый инструмент продвижения, то нужно быть готовым к его применению. В Agile важнее реагировать на изменения, чем придерживаться изначального плана.
7. Множество мини-экспериментов лучше, чем один большой. Долгосрочные исследования с множеством факторов и переменных менее достоверны, чем локальные краткосрочные тестирования.

Если не углубляться в теоретизирование философии гибких методологий, с практической точки зрения Agile-маркетинг строится на основе HADI цикла.

Работа по циклу HADI

HADI – это простая модель, которая включает четыре последовательных шага:

1. Гипотеза. Генерация идей по улучшению маркетинговых активностей.
2. Действие. Внедрение и тестирование гипотез.
3. Данные. Анализ статистических показателей по итогам внедрения гипотез.
4. Вывод. Заключение относительно работоспособности выдвинутых идей.

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

Критически важно здесь придерживаться следующих правил:

• Длина одного цикла должна составлять не более двух недель. В случае если выдвинутые гипотезы требуют для проверки большего времени, то их режут на этапы. Весь смысл в краткосрочных рывках и высоком темпе;
• Гипотезы формулируются строго по SMART. То есть должны быть конкретны (Specific), измеримы (Measurable), достижимы (Attainable), релевантны (Relevant) и ограничены во времени (Time-bound).
• За один подход генерировать по 10-15 гипотез. Практика показывает, что лучшие идеи приходят в конце, когда очевидное проговорено.
• Держаться высокого ритма работы. Для контроля темпа даже выделяют отдельного человека – Scrum-мастера, который следит за тем, чтобы не простаивали задачи.
• Вовлекать коллектив в процесс. Главное здесь — это заинтересованные лица и немного фана, потому что Agile — это всегда про команду и людей, и только потом про процессы.

Этап полного цикла в Agile-маркетинге

Кем реализуется Agile-подход в маркетинге

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

Минимальный состав маркетинговой команды включает три роли:

1. Владелец продукта (Product Owner) — тот, кто задает вектор работы, курирует и смотрит на проект «сверху», оценивая картину целиком. В небольших компаниях это может быть директор по маркетингу или непосредственно руководитель компании;
2. Специалист по приоритетному направлению. Специалист подбирается в зависимости от того, какой канал продвижения будет основным. При планировании комплексного подхода, специалистов может быть несколько, например: контекстолог, сеошник, контент-маркетолог.
3. Веб-мастер. Ведет работу с сайтом и посадочными страницами.

Команду можно усилить привлечением дополнительных экспертов, например:

• Дизайнер. Отвечает за графический креатив, баннеры и т.д.
• Веб-аналитик. Занимается расшифровкой и сопоставлением аналитических показателей, вычисляет степень эффективности рекламных инструментов.
• Scrum-мастер – помогает команде освоиться с фреймворком и решать различные трудности на пути к созданию идеального продукта.

Правила взаимодействия руководителя с Agile-командой:

• задать вектор пути, то есть единую глобальную цель в цифрах;
• определить административные и материальные ресурсы;
• позволить команде совершать ошибки. В Agile работает принцип «fail fast»: чем быстрее и больше совершается мелких ошибок, тем быстрее достигается цель;
• предоставить свободу действий, не мешать и не руководить на уровне микро-менеджмента.

Процесс выработки гипотез и отчеты

Команда будет работать с двумя типами отчетов:

• Файл с метриками проекта. Необходим для достижения целей и понимания пути. Помогает избежать ошибку команды, когда сутью изменений становятся сами изменения, а не улучшение бизнес-показателей. Здесь собираются KPI рекламных кампаний (конверсии, CTR, трафик, продажи и т. д.).

Пример отражения метрики интернет-магазина

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

• условие «если» что хотим сделать?
• эффект «то»: что желаем получить в результате?
• обоснование «почему»: почему это заработает?
• действия: какие шаги следует совершить для проверки идеи?

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

• «Вера» — степень уверенности команды, что идея принесет планируемый результат. От 0 до 3, где 0 — абсолютно не верю, а 3 — уверен, что сработает;
• «Сложность» — как много ресурсов нужно для начала реализации. От 1 до 3, где 1 — задача на одного человека в течение дня, а 3 — работа команды на полный спринт.

Затем выполняется расчёт «веса» гипотезы с помощью формулы «вера, деленная на сложность».

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

Такие сессии следует проводить 1 раз в 3-4 цикла и обновлять общий список гипотез. Для актуализации и сверки результатов с планами к обоим отчетным файлам рекомендуется обращаться в начале каждого цикла. Молодые Agile-команды часто игнорируют рабочие файлы и несвоевременно их актуализируют.

Заключение

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

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

Что такое Agile: от идеи до потенциальных проблем | WEEEK | Блог

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

В чём идея

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

«Гибкость» заключается в способности agile-команды постоянно адаптироваться к изменяющимся условиям и достигается за счёт:

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

Краткая история Agile

Гибкий подход начинает своё существование где-то с первой половины XX века (хотя, есть мнение, что что-то на него похожее было и раньше). Примерно в 30-х физик Уолтер Шухарт применяет итеративный подход Plan-Do-Study-Act, которым делится со своим учеником Ульямом Демингом (сейчас мы знаем этот подход к управлению, как Цикл Деминга). После окончания Второй мировой, компания Toyota (та самая, где придумали Lean, Kanban и много чего ещё, связанного с Agile) нанимает Деминга обучить своих менеджеров.

В следующие годы во многих компаниях придумывают свои методики гибкого управления: Scrum, XP, FDD и так далее. Но про «agile» никто не говорит до 2001 года, пока 17 разработчиков, практикующих методики гибкого управления, не собираются вместе и не составляют Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development или просто Agile Manifesto). Здесь и возникает понятие «agile», вокруг которого сегодня столько разговоров.

Основные ценности Agile-методологии

В статье про методы управления проектами я дал такое определение:

Методология — набор методов и принципов, подкреплённых теорией.

Так вот теория в случае с Agile — это ценности, описанные в Agile Manifesto:

• Люди и взаимодействие важнее процессов и инструментов. Если в твоей команде есть принципы, традиции, структуры, инструменты или условия, которые явно мешают работе — от них следует избавиться. Люди сами должны выбирать способ организации, набор процессов, используемые инструменты. В конце концов, всё это должно помогать работе, а не мешать.
• Работающий продукт важнее документации. Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.
• Сотрудничество с заказчиком важнее согласования условий контракта. Посмотри немного дальше согласования ТЗ и сметы. Нет смысла портить отношения с заказчиком, пусть и ценой своевременной оплаты. Если ты не можешь согласовать работы и портишь общение, в итоге потеряешь и этого клиента, и, возможно, следующих. Любые контракты, документы и соглашения должны идти на руку твоим взаимоотношениям с клиентами, а не портить их.
• Готовность к изменениям важнее следования первоначальному плану. Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.

Ещё в Манифесте описаны принципы, но скорее в попытке разжевать ценности. Так что приводить я их здесь не буду. Если хочешь, сходи почитай на Википедии.

Какие могут быть проблемы

Ай, какой классный Agile, да? Увы, хотя его и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.

Я вижу три проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:

• Сложно отказаться от концепции «начальник — подчинённый». Ведь Agile — это не способ планирования, а философия работы всей команды. Далеко не каждая компания сможет спокойно пережить подобную трансформацию.
• Не все готовы к по-настоящему командной работе. Многим людям комфортнее работать в одиночку, отчитываться перед руководством и никуда не лезть. А в случае с Agile всем придётся во всём разбираться и постоянно участвовать в чужой работе.
• Не все готовы к тому, что часть времени может просто пропасть. Допустим, команда работала над задачей, а потом оказалось, что цели проекта поменялись и продолжать почти законченную работу нет смысла. Все твои усилия были напрасны. Это психологически сложная ситуация, которая может запросто убить всю мотивацию.

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

Agile-методология позволяет то, что не позволяет каскадная модель — создавать качественные продукты без подробнейшего плана на все этапы. Всё благодаря итеративности, обратной связи клиентов и сотрудников и самоорганизации команды.

Главное, помни, что Agile – это методология и философия. Чтобы применять всё это для управления проектами, нужно собрать свою методику или выбрать одну из существующих — о них я расскажу в следующих статьях.

Просто о сложном: agile-разработка / Далее

Что было до аджайла

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

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

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

Agile Manifesto

Со временем разработчики стали тестировать и изменять продукт во время работы. Так появились новые техники, которые назвали гибкими. В 2001 году 17 представителей профессии собрались в горной деревне штата Юта, покатались на лыжах и заодно обсудили свои подходы к разработке.

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

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

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

Как команды работают по аджайлу

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

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

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

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

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

Кое-что еще

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

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

Процесс работы по Scrum: спринты, циклы разработки, standup-митинги

Канбан-доска: карточки перемещаются по колонкам-этапам

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

Какому продукту точно нужен аджайл?

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

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

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

методология управления проектами, конкретные примеры

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

Суть

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

У этих методов есть общие признаки: Agile переводится как «подвижный», «проворный», «живой», «верткий», «гибкий», «способный изменяться легко и быстро». Отсюда и 4 ценности agile: 

1. «Люди и взаимодействие важнее процессов и инструментов»;
2. «Работающий продукт важнее исчерпывающей документации»;
3. «Сотрудничество с заказчиком важнее согласования условий контракта»;
4. «Готовность к изменениям важнее следования первоначальному плану».

«Важнее» не значит, что нужно забывать про «процессы и инструменты», «исчерпывающую документацию» и т. д. Это значит, что если сроки поджимают, то нужно правильно расставить приоритеты.

Четыре ценности agile поясняются 12-ю принципами. Последовательность их появления будет зависеть от логики повествования. Начнем мы с того, как эти ценности реализуются на практике в каждом методе agile:

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

К семейству Agile относится и Scrum, который мы подробно разберем. Стоит отметить, что у него нет четкого определения. Одни называют Scrum методом, другие – фреймворком, то есть набором правил, на котором в индивидуальном порядке создается метод. Думается, определение зависит от того, насколько подробно вы сами будете внедрять этот метод/фреймворк.

Scrum

Третий принцип Agile: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно». У игроков в регби – та же задача. Если игра приостанавливается, то и энтузиазм падает. Для его поднятия используется scrum (схватка): команды вплотную становятся друг напротив друга, а затем начинают толкучку с целью получить мяч. 

Разработчики программ вдохновились этим и назвали свой метод работы Scrum. Как и в регби, главное в методе – команда и отношения внутри нее. Она имеет следующую структуру:

• Product owner («Владелец Продукта»). Он знает, каким должен быть конечный продукт для конкурентоспособности на рынке, и ставит требования по его разработке. Обратите внимание на четвертый принцип agile: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе».
• SCRUM-мастер. Это – не лидер, а «лидер-слуга». С одной стороны, он направляет команду, объясняет ей суть поставленных задач. С другой стороны, он создает облегченные условия для ее самореализации и самостоятельной работы, удовлетворяя невысказанные потребности. Тут можно ввести пятый принцип agile: «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд».
• Команда Разработки. Их цель можно выразить шестым принципом agile: «Работающий продукт – основной показатель прогресса». В команде – от 3 до 9 человек – иначе работа будет неэффективна. В нее входят представители всех профессий, необходимых для создания этого продукта. Если команда занимается разработкой сайтов, то в нее будут входить программист, дизайнер, копирайтер и т. д.

Работа Scrum-команды делится на спринты. Sprint – еще один спортивный термин, обозначает он бег на короткую дистанцию. В нашем случае дистанция изменяется не в метрах, а в днях и неделях. Максимальный рекомендуемый размер спринта – один месяц. За это время команда должна сделать готовый продукт.

Делать отсрочку крайне нежелательно. Это отражено в седьмом принципе agile: «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения».

В Спринте выделяются следующие события:

1. Планирование Спринта.
2. Ежедневный Скрам. 15-минутное собрание Команды Разработки, на котором планируется работа на следующие 24 часа.
3. Обзор Спринта. В конце Спринта обсуждаются его итоги.
4. Ретроспектива Спринта. Предлагаются улучшения для следующего Спринта.

События напоминают классический Цикл Деминга (plan – do – check – act), только этап «действие» как бы вбирает в себя все остальные. И это неудивительно: agile – вечное движение вперед. 

Разберем пример, разбивая Спринт на События.

Планирование Спринта

Обратимся вновь к команде, которая занимается разработкой сайтов. Не считая Владельца продукта и Scrum-мастера, в нее войдут: контент-менеджер, SEO-специалист, веб-программист, HTML-верстальщик, веб-дизайнер. Для планирования Спринта им нужно:

1. Бэклог Продукта. Это список требований к продукту, который формирует Product Owner с помощью Команды Разработки. Каждое требование сопровождено необходимым комментарием, оценкой объема работы и ценности среди других требований. Работа с Бэклогом не завершается после Планирования Спринта. Наоборот, постоянное внесение изменений облегчит проведение этого События в будущем. 

Например, готовый сайт должен находится в топ-5 выдачи. У него будет ограниченное количество разделов, чтобы пользователь не запутался. На каждой странице должно быть какое-то минимальное количество картинок. И так – по каждому сайту, который нужно создать или отредактировать. 

1. Последний Инкремент продукта. Инкремент – это все, что удалось сделать по итогам того или иного Спринта. Предыдущий Инкремент нужен для того, чтобы предсказать производительность команды. Например, сколько сайтов удалось создать, сколько было отредактировано, удалось ли ввести сайт в топ-5.

Затем определяется:

• что будет сделано. Здесь последнее слово – за Командой Разработчиков. Она должна взять Бэклог и определить, с какими заказами справится, сколько сайтов успеет сделать; 
• как это будет сделано. Здесь основной метод – декомпозиция. Команда берет то, что выбрано в Бэклоге, и разбивает это на более мелкие задачи. Например, подобрать список ключевых слов, написать текст, проверить его на содержание ключевиков с помощью определенных сервисов.

На Событие уходит максимум 8 часов. И это совсем не много: речь идет о плане на весь месяц. 

Ежедневный Скрам

Впервые это Событие происходит через 24 часа после окончания Планирования Спринта и начала работы. Затем постоянно повторяется с интервалом в сутки: команду будет мотивировать, если Событие будет происходить в одно и то же время.

Зачем это нужно? Ответ кроется в восьмом принципе agile: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

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

• Если работать так, как в предыдущие сутки, будет ли достигнут заявленный Инкремент продукта?
• Как устранить препятствия, с которыми сталкивались в предыдущие 24 часа?
• Как организовать работу сегодня?
• Сможем ли мы в конце концов достичь заявленного Инкремента?

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

Настало время для девятого принципа agile: «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта».

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

На все собрание дается 15 минут. Но лучше быстрее. Идеал Scrum – это регбисты, которые стоят лицом со лицу со своей проблемой и готовы всегда вступить в бой.

Обзор Спринта

Происходит он в конце спринта, когда Продукт должен быть готов. В нем участвует не только Scrum-команда: 

• владелец Продукта приглашает заказчиков. Именно на основе их заказов он во время Планирования сформировал Бэклог Продукта со всеми требованиями;
• другие Scrum-команды с похожими Бэклогами и Инкрементами.

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

Затем слово берут остальные. Они задают вопросы – Команда Разработчиков на них отвечает.

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

Проводить Событие нужно в любом случае, так как это – мост между командой и заказчиками. Вспомните 3-ю ценность agile. Обратите внимание на десятый принцип: «Изменение требований приветствуется, даже на поздних стадиях разработки».

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

Как правильно провести Обзор Спринта?

• Помните о дружеской атмосфере, которая должна царить между всеми присутствующими. 
• Помните, что на Обзоре будут присутствовать те, кто совсем не знаком с Бэклогом. Поэтому четко озвучьте его в начале.
• В остальном – не сильно готовьтесь к самому выступлению (создание презентации, распределение ролей и т. д.). Помните, что планированию в agile отводится минимум времени. Лучшее средство – сделать обзор динамичным и ориентированным на конкретный продукт. Вот соответствующий принцип agile, двенадцатый по счету: «Простота – искусство минимизации лишней работы – крайне необходима».
• Если это возможно, дайте заказчикам самим «поиграть» с продуктом: посмотреть готовый сайт, полазить на нем.

Четких временных рамок нет. Но помните: чем лаконичнее Событие в Scrum, тем лучше.

Ретроспектива Спринта

Вот здесь присутствует только Scrum-команда, так как они решают свои, внутрисемейные проблемы. Плана События нет. Главное – помнить, что вы ищете ответ на вопросы: 

• Что было хорошо?
• Что могло бы быть лучше?
• Что будет улучшено?

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

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

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

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

Конечно, полностью agile подойдет не для каждого бизнеса:

• Производство не всех продуктов можно разбить на этапы, которые будут длится максимум один месяц. Допустим, производится сложное оборудование. И через месяц после начала работы заказчики приглашаются на Обзор Скрипта. Что они увидят? Незаконченный механизм? Что они могут попробовать, «потрогать»?
• Трудно соблюсти рамки в 3–9 человек. Например, над созданием сайта могут работать всего лишь копирайтер, занимающийся текстами, и программист, который возьмет на себя верстку. Зачем им Scrum-мастер?

Но элементы Scrum и Agile в целом, идея быстрой, итеративной работы могут вдохновить многих на совершенствование своего рабочего процесса.

Agile-манифест и Основополагающие принципы Agile-манифеста

Agile-манифест разработки программного обеспечения

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

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

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

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:

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

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

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

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

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

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

— Работающий продукт — основной показатель прогресса.

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

— Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.

— Простота — искусство минимизации лишней работы — крайне необходима.

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

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

Наши Тренинги и Сертификации по Аджайл 

Подпишитесь на наш Фейсбук, чтобы быть в курсе событий и Акций на билеты

Agile и бережливое производство: что общего между Lean и DevOps | by Nick Komissarenko

Чтобы сделать курс Аналитика больших данных для руководителей еще более интересным, мы продолжаем включать в него темы про методы производственной оптимизации. Сегодня рассмотрим, что такое бережливое производство (Lean) и почему Agile вообще и DevOps в частности активно используют принципы этой концепции. Также читайте в нашей статье, чем Lean отличается от системы менеджмента качества (СМК) и методики 6 сигм.

Что такое Lean: бережливое производство для чайников

Прежде всего, сделаем краткий ликбез по теме бережливого производства (Lean). Эта концепция управления предприятием предполагает непрерывное устранение всех видов потерь с целью максимальной оптимизации бизнеса для наилучшего удовлетворения потребителя. Она основана на производственной системе японской компании Toyota, благодаря которой автоконцерн вышел из послевоенного кризиса и устал успешной организацией в мировом масштабе. Идеи бережливого производства отражены во множестве современных методов управления качеством, наиболее популярными из которых считаются следующие [1]:

· вытягивание, когда объёмы продукции и сроки её изготовления на каждом производственном этапе определяются исключительно потребностями заказчика, а не заранее разработанным и спущенным сверху планом;

· точно вовремя (Just in Time), когда движение материальных потоков организовано так, что все материалы и компоненты, необходимые для реализации готовой продукции, поступают в необходимом количестве, в нужное место и точно к назначенному сроку, не занимая место на складах;

· канбан — визуализация состояния рабочих задач для повышения прозрачности процессов и равномерного распределения нагрузки между их участниками;

· быстрая переналадка оборудования (SMED, Single-Minute Exchange of Dies), когда его ремонт и переоснастка выполняются с высокой скоростью по заранее определенным схемам;

· картирование потоков создания ценностей (VSM, Value Stream Mapping) для визуализации процессов создания продуктов, представляющих ценность для конечного потребителя с целью выявления лишних операций и их устранения. Пример такой VSM-карты мы рассматривали в этой статье.

· автономизация оборудования, когда оно способно самостоятельно обнаружить проблемы, диагностировать и устранять собственные неисправности, сразу останавливая производственный процесс и сигнализируя об этом при выявлении дефектов в качестве продукции или задержек в работе;

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

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

Иногда к методам бережливого производства еще относят концепцию 6 сигм, основанную на статистических методах управления качеством для измерения отклонений реальной продукции от заданного эталона и сокращения дефектов. Однако, при общих целях повышения эффективности рабочих процессов и итоговых результатов, подход 6 сигм отличается от принципов Lean, а потому не входит в понятие бережливого производства. Тем не менее, на практике возможно совместное применение этих концепций для комплексного улучшения производственной деятельности и повышения удовлетворенности клиентов [2]. Не случайно профессиональный стандарт бизнес-аналитика, руководство BABOK, включило методы Lean и 6 сигма в наиболее часто используемые техники процессного анализа.

СМК, DevOps и Lean: сходства и отличия

В отличие от типовой системы менеджмента качества, которая декларативно описывает, что нужно делать, но не говорит, каким образом, принципы бережливого производства подробно рассказывают, как снизить потери или вообще избавиться от них [3]. В частности, метод картирования потоков создание ценностей пошагово регламентирует, как создать VSM, а система 5S вообще представляет собой простой и дешевый способ рациональной организации рабочего пространства.

Также важным свойством Lean-концепции является универсальность ее методов, которые можно применять не только для эффективного управления заводом или другим промышленным предприятием. Эти подходы отлично подходят и к области ИТ. К примеру, из 12 принципов Манифеста Agile почти половина полностью повторяют идеи Lean [3]. Особенно четко это прослеживается в философии DevOps, направленной на ускорение процессов разработки и эксплуатации программного обеспечения с помощью средств автоматизации повторяемых процессов и управления инфраструктурой как кодом [4].

Вообще тему использования принципов Lean в разработке программного обеспечения впервые раскрыли Мэри и Том Поппендики, опубликовав книгу «Lean Software Development» в 2003 году. Распространению их идей поспособствовала популяризация Agile-подходов к организации процессов в ИТ и других сферах деятельности [5]. В следующей статье мы рассмотрим, как некоторые методы бережливого производства реализованы в технологиях Big Data.

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

От философии к практикам: как связаны Lean и Agile

Больше подробностей про методы бережливого производства и их применение в цифровизации бизнеса и аналитике больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве:

Аналитика больших данных для руководителей
Анализ и оптимизация бизнес-процессов

Смотреть расписание занятий

Зарегистрироваться на курс

Источники

1. https://ru.wikipedia.org/wiki/Бережливое_производство

2. https://ru.wikipedia.org/wiki/Шесть_сигм

3. https://probusiness.io/management/3811-lean-eto-ne-tolko-pro-proizvodstvo-komu-i-dlya-chego-nuzhna-eta-metodologiya.html

4. https://www.litres.ru/oleg-skrynnik/devops-dlya-it-menedzherov-48411311/

5. https://ru.wikipedia.org/wiki/Бережливая_разработка_программного_обеспечения

Harvard Business Review Россия

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

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

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

Манифест — то, в чем все эти люди смогли максимально сойтись.

Для методологов проектного управления Agile делится на:

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

• 4 базовых принципа и 12 правил — философская основа Agile.

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

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

Любая технология или подход переживают различные стадии: от популярности и очарования, до бесполезности и забытья. Компания Gartner, знаменитая своими исследованиями ИТ-рынка, описала эту динамику циклами хайпа — Hype cycle.

Первая стадия: сначала никто о технологии не знает, но постепенно о ней начинают говорить — хайп начинает расти.

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

Далее выясняется, что она работает не всегда, не везде, не у всех.

Потом наступает разочарование.

На следующей стадии приходит понимание, что где-то технология все-таки применима, а кое-где по-настоящему эффективна.

Последняя стадия, следующая за этим пониманием, — выход на плато производительности.

Эти циклы хорошо иллюстрирует пример с блокчейном. Технология существует с 2008 года, но тогда о ней практически никто не слышал. Два года назад технология достигла пика завышенных ожиданий. Эксперты предвещали, что все перейдут исключительно на блокчейн и он полностью поменяет мир. То же происходило и с появлением кино, дополненной реальности, интернета, электромобиля. Помните классическое: «Вообще со временем телевидение перевернет жизнь всего человечества. Ничего не будет. Ни кино, ни театра, ни книг, ни газет, одно сплошное телевидение!»? Это тот же цикл.

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

Agile для бренда или результата

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

Зачем Agile Сбербанку? На мой взгляд, Сбербанк внедрял Agile, потому что руководство хотело позиционировать себя как инновационную, передовую ИТ-компанию, а не как традиционный и консервативный банк. Они убедили многих, что стремительно двигаются в сторону цифровизации и технологизации.

Упорядоченность и запутанность

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

Одна из самых известных — модель Дейва Сноудена («Киневин») CYNEFIN. Модель Киневин говорит о системах в широком смысле, как о наборе элементов и связей между ними. Касательно бизнеса проект — это система, подразделение — система, отдельная команда — тоже система. Все системы бывают:

упорядоченные простые, с понятной причинно-следственной связью. Табуретка на 4 ножках. Отпилишь две ножки — табуретка упадет. Велосипед. Крутишь педали — едет. Все понятно;

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

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

хаотические. Что бы ни делали — непонятно, как это устроено.

Представим, что нужно выпустить брошюру к конференции, а сотрудники никогда не занимались издательством или публикациями? Это сложная система, но мы проанализировали ее этапы и привлекли экспертов, которые подсказали как нужно. Другой уровень — нужно выпустить журнал с использованием виртуальной реальности для тех, у кого есть очки дополненной реальности. Они смогут в 3D-формате взаимодействовать со статьями. Технически это можно сделать, но совершенно непонятно, как все это будет работать и нужно ли кому-то. Экспертов позвать нельзя, потому что их просто нет. Это и есть Agile, ведь нужно экспериментировать. Как раз для таких запутанных и комплексных историй он подходит лучше всего.

Мы проводим небольшие эксперименты, создаем продукт, который нам удается собрать на свой страх и риск. Этот продукт в Agile называется MVP (minimal viable product) или минимально жизнеспособный продукт. MVP быстро оказывается на рынке, и можно протестировать насколько эффективно он помогает решать проблемы целевой аудитории, получить обратную связь и доработать продукт в дальнейшем, экономя средства.

Agile или не Agile?

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

Стоит применять Agile, когда существуют:

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

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

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

Нецелесообразно применять Agile, когда существуют:

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

Отсутствие возможности финансировать доработки. Изменения и многочисленные доработки продукта могут значительно увеличить стоимость разработки и сделать Agile-подход неприемлемо дорогим и экономически неоправданным.

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

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

Чек-лист готовности

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

Что нужно проверить до начала работы по Agile.

Команда и стейкхолдеры готовы принять принципы и правила Agile-подхода. Принципы и правила прописаны в манифесте, в множестве книг и статей. Самым сложным для нашей ментальности является «право на ошибку». Для неопределенности ошибки — это нормально. Аgile — это и есть институционализированный метод проб, ошибок, экспериментов. Делаем, смотрим, что получается, что нет, быстро переделываем. Работает принцип «fail fast, fail safe» (ошибайся быстро, ошибайся безопасно). Неважно, что ошибся, важно, что ошибку обнаружили, распознали и быстро исправили. Это один из очень серьезных барьеров на пути внедрения Agile в России, где у многих осталось восприятие, что «у каждой аварии есть имя, фамилия и отчество». Если команда сделала что-то неправильно, не должно быть «расстрелов».

Есть Agile-команда. Agile-команда — это непростая команда. В ней должны сочетаться ряд характеристик:

• Она должна быть компактная: 7 сотрудников плюс-минус 2 человека. Ее еще называют «2 pizza team», команда, которую можно накормить двумя пиццами. То есть совсем небольшая. Техники масштабирования Agile на большие команды существуют, но они очень и очень нетривиальны. Начинать с них точно не стоит;

• В команде должны присутствовать сотрудники, обладающие компетенциями, необходимыми для разработки продукта и представляющие все подразделения, которые необходимы для разработки продукта;

• У сотрудников должно быть достаточно времени для работы в команде. Крайне желательно, чтобы они все свое время посвящали работе над проектом, принцип «100 на 0» — 100% вовлечения;

• Крайне желательно, чтобы все сидели вместе, в одном помещении;

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

Есть владелец продукта (заказчик), который:

• уполномочен единолично определять все требования к продукту и приоритетность задач. В нашей российской или «византийской» системе управления получить такое право непросто;

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

• доверяет команде. Владелец продукта определяет, что делать, команда определяет, как делать. Владелец не вмешивается в процесс решения задач, не говорит: «Не так вы работу работаете, я сейчас разъясню. Давайте это отложим и лучше сделаем так». Agile не приемлет микроменеджмент.

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

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

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

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

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

Об авторе. Павел Алферов — профессор бизнес-практики Московской школы управления «Сколково».

12 главных принципов Agile — ProjectManager.com

Agile — это… сложно. Это методология или что-то еще? Быстрый поиск приведет к спорам. Что такое Agile? Это отличный способ управлять своим проектом, если вы ищете более свободную структуру, которая допускала бы изменения и сотрудничество.

Если вам интересно узнать об истоках гибкой разработки, то лучше всего вернуться к Agile Manifesto, созданному семнадцатью разработчиками программного обеспечения в 2001 году. Авторы манифеста согласовали 12 принципов, определяющих, как запускать гибкий проект.

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

Agile требует гибких инструментов для динамических проектов. Используйте доски канбан ProjectManager.com для управления всеми своими гибкими проектами!

12 Agile Principles

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

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

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

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

3.Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.

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

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

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

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

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

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

6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.

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

7. Работающее программное обеспечение — это главный показатель прогресса.

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

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

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

9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.

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

10. Простота — искусство максимизировать объем работы

, а не — очень важна.

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

11. Лучшие архитектуры, требования и проекты возникают из самоорганизующихся команд.

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

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

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

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

Объяснение 12 принципов гибкого управления проектами

Согласно годовому отчету PMI Pulse of the Profession, 48% проектов не завершаются в запланированные сроки, 43% превышают первоначальный бюджет и 31% проектов не соответствуют первоначальным целям и бизнес-намерениям.Это звучит не очень оптимистично.

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

12 принципов гибкости

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

# 1 Удовлетворение клиентов ранней и непрерывной доставкой

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

Как видите, удовлетворение потребностей клиентов основывается на 12 принципах. Ранняя и непрерывная доставка увеличивает вероятность удовлетворения требований клиентов и способствует более быстрой окупаемости инвестиций.

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

# 2 Добро пожаловать! Изменение требований даже на поздней стадии проекта

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

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

# 3 Доставляйте ценность часто

Третий принцип управления проектами Agile изначально гласит: «поставлять работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких временных рамок» . Его основная цель — уменьшить размеры пакетов, которые вы используете для обработки работы.

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

# 4 Разбейте свой проект

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

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

10 лет опыта использования канбана в 1 бесплатной книге:

Руководство по Канбану для менеджера проекта

# 5 Строить проекты вокруг мотивированных людей

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

Как и в исходном тексте после манифеста Agile, вам необходимо « строить проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы».

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

# 6 Самый эффективный способ общения — лицом к лицу

«Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение».

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

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

# 7 Рабочее программное обеспечение — главный критерий прогресса

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

Если результат вашей работы не такой, как ожидает ваш клиент, у вас проблемы

# 8 Поддержание устойчивого рабочего темпа

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

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

# 9 Непрерывное совершенство повышает гибкость

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

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

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

# 10 Главное в простоте

Исходное содержание этого принципа может немного сбивать с толку, поскольку он заявляет: « Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение» . Тем не менее, это очень практично.

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

# 11 Самоорганизующиеся команды приносят наибольшую пользу

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

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

# 12 Регулярно размышляйте и корректируйте свой стиль работы для повышения эффективности

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

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

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

Удачи!

Попробовать Kanbanize бесплатно

В итоге

Реализация 12 принципов Agile поможет вашей организации:

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

Agile Manifesto | 4 ценности и 12 принципов Agile: объяснение

Agile Manifesto — это основа большинства современных методологий управления проектами.В нем четыре основные ценности, дополненные 12 принципами. Руководители проектов используют эти принципы для создания исключительных продуктов, обладающих как ценностью, так и качеством, при этом оставаясь в рамках заданных ограничений проекта.

Настоящий документ, состоящий из ценностей и принципов гибкого подхода, был разработан в 2001 году группой из 17 инженеров-программистов на горнолыжном курорте в Юте. «Agile Alliance» был создан, чтобы бросить вызов статус-кво и полностью изменить подход к решению проблем и управлению проектами.

То, что начиналось как руководство по разработке программного обеспечения, теперь стало общепринятой философией управления проектами. Сегодня Agile-процессы используются не только командами разработчиков программного обеспечения, но и почти всеми функциями бизнеса. Многие из первоначальных членов Agile Alliance продолжили разработку других популярных фреймворков, таких как методология Scrum, методология Kanban, Crystal и Integrated Agile на основе методологии Agile.

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

Почему была разработана методология Agile?

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

Команды

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

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

4 значения Agile Manifesto

1. Люди и взаимодействие важнее процессов и инструментов

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

2. Рабочий продукт поверх исчерпывающей документации

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

3. Сотрудничество с клиентами по согласованию контрактов

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

4. Реагирование на изменения в соответствии с планом

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

12 принципов Agile Manifesto

1. Удовлетворенность клиентов за счет непрерывной поставки продукта

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

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

2. Разделите большие объемы работы на более мелкие и достижимые задачи для более быстрого выполнения и упрощения интеграции изменений

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

3. Соблюдать установленные сроки поставки рабочего продукта

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

4. Все заинтересованные стороны должны часто сотрудничать, чтобы гарантировать, что проект идет в правильном направлении

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

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

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

6. Предпочитайте личное общение другим методам

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

7. Работающее программное обеспечение — главный показатель прогресса

Единственный фактор для измерения успеха — это поставка работающего продукта, удовлетворяющего потребителя. До Agile было много критериев успеха, и это приводило к падению качества конечного продукта.

8.Постарайтесь поддерживать постоянный темп развития

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

9. Поддерживайте качество продукта, обращая внимание на технические детали

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

10. Сохраняйте простоту

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

11. Содействовать самоорганизации в коллективе

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

12. Регулярно размышляйте о своей работе для постоянного улучшения

Методологии

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

Начало работы с Agile

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

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

Дополнительные ресурсы

---

---

Каковы 4 ценности Agile?

Agile Manifesto состоит из четырех ключевых значений:

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

Давайте подробно рассмотрим каждый из них:

Узнайте больше об Agile Manifesto.

Значение 1: отдельные лица и взаимодействия

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

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

Значение 2: Рабочее ПО

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

Agile Manifesto ставит поставку программного обеспечения вашим клиентам как один из наивысших приоритетов. Затем вы можете собрать отзывы, которые помогут вам улучшить будущие выпуски.

Значение 3: Сотрудничество с клиентами

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

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

Значение 4: реакция на изменение

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

Проблема со статическими дорожными картами в том, что мы не живем в статичном мире. Потребности и требования всегда меняются, а приоритеты всегда меняются. Эта статическая дорожная карта скоро устареет.

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

Agile Manifesto также состоит из 12 принципов. О них читайте здесь.

. . .

Productboard — это система управления продуктами, которая позволяет командам быстрее выводить нужные продукты на рынок. Productboard, созданная на основе структуры Product Excellence, служит специальной системой записи для менеджеров по продукту и помогает каждому выбрать нужные функции для создания следующей. Получите доступ к бесплатной пробной версии Productboard сегодня.

12 принципов гибкости | Товарная доска

Наряду с четырьмя ценностями Agile Manifesto, вам необходимо знать 12 принципов. Эти принципы более подробно раскрывают четыре ценности.

Давайте посмотрим:

Принцип гибкости 1

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

Всегда было важно, чтобы ваши клиенты были довольны.С продуктами SaaS это еще более верно. Вашим клиентам легко уйти и найти другой продукт, если они недовольны.

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

Принцип гибкости 2

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

Море SaaS постоянно меняется. Единственный способ удержать голову над водой — это адаптироваться.

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

Принцип гибкости 3

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

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

Принцип гибкости 4

«Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта».

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

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

Принцип гибкости 5

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

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

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

Принцип гибкости 6

«Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.”

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

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

Принцип гибкости 7

«Работающее программное обеспечение — главный критерий прогресса».

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

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

Принцип гибкости 8

«Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп бесконечно ».

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

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

Принцип гибкости 9

«Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность».

Agile Manifesto побуждает команды постоянно выпускать новые функции и обновления продукта. Несмотря на это, он также признает важность поддержания качества выпусков.

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

Принцип гибкости 10

«Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение».

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

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

Принцип гибкости 11

«Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами».

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

Принцип гибкости 12

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

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

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

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

. . .

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

Lean-Agile Mindset — масштабируемая гибкая структура

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

— доктор Кэрол С. Двек, писатель и профессор психологии Стэнфордского университета

Lean-Agile Mindset — это комбинация убеждений, предположений, взглядов и действий руководителей и практиков SAFe, которые принимают концепции Agile Manifesto и Lean-мышления.Это личная, интеллектуальная и лидерская основа для принятия и применения принципов и практик SAFe.

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

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

Осведомленность о мировоззрении и открытость к изменениям

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

Итак, как можно изменить мышление? Он начинается с осознания того, как сформировалось текущее мировоззрение. Также очень важно развивать веру в то, что мышление можно развивать и улучшать (установка на «рост», как показано на рисунке 1). Лидеры должны оставаться открытыми для возможности того, что существующее мышление, основанное на традиционных методах управления, должно развиваться, чтобы направлять организационные изменения, необходимые для того, чтобы стать экономичным предприятием. [3] Рис. 1. Принятие нового образа мышления требует веры в то, что новые способности можно развить с помощью усилий.

В следующих двух разделах описаны ключевые элементы Lean и Agile, которые составляют основу мышления Lean-Agile.

Экономичное мышление с помощью SAFe House of Lean

Первоначально заимствованные из бережливого производства, принципы и практика бережливого мышления применительно к разработке программного обеспечения, продуктов и систем теперь являются глубокими и обширными [2]. Например, Уорд [3], Райнертсен [4], Поппендик [5], Леффингвелл [6] и другие описали аспекты бережливого мышления, поместив многие из основных принципов и практик в контекст разработки продукта. Бережливое мышление можно резюмировать следующим образом [7]:

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

Наряду с этими основными тенденциями бережливого мышления, SAFe House of Lean, как показано на рис. 2, был вдохновлен конструкциями Lean от Toyota и других компаний.

Рис. 2. SAFe House of Lean

Цель — ценность

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

Компонент 1 — Уважение к людям и культуре

Подход Lean-Agile не реализует себя и не выполняет никакой реальной работы — это делают люди. Уважение к людям и культуре — основная потребность человека.При уважительном отношении люди получают возможность развивать свои методы работы и улучшать . Руководство побуждает людей меняться и может направлять их к лучшим способам работы. Однако именно команды и отдельные лица изучают навыки решения проблем и рефлексии и несут ответственность за внесение соответствующих улучшений.

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

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

Столб 2 — Поток

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

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

Принципы

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

Компонент 3 — инновации

Flow создает прочную основу для создания ценности. Но без инноваций и продукт, и процесс будут неуклонно сокращаться. Для поддержки этой важной части SAFe House of Lean лидеры Lean-Agile используют следующие практики:

• Нанимать, коучить и наставлять в сфере инноваций и предпринимательства среди сотрудников организации
• Пойдите и посмотрите… выйдите из офиса и перейдите на рабочее место, где производятся ценности, создаются и используются продукты (известные как гемба ).Как сказал Тайити Оно: «Никаких полезных улучшений за столом никогда не изобреталось».
• Предоставьте людям время и пространство для творчества, чтобы внедрить целенаправленные инновации. Это редко может произойти при 100-процентной загрузке и ежедневном тушении пожара. Итерация инноваций и планирования SAFe — одна из таких возможностей.
• Применяйте непрерывное исследование, процесс постоянного изучения рынка и потребностей пользователей, быстрого получения отзывов об экспериментах и ​​определения видения, дорожной карты и набора функций, которые выводят на рынок наиболее многообещающие инновации.
• Подтвердите инновации с клиентами, а затем без пощады или вины принимайтесь за решение, когда гипотеза должна измениться.
• Используйте как стратегическое мышление сверху вниз, так и органические командные инновации, чтобы создать синергетический «инновационный ритид», который обеспечивает приливную волну новых продуктов, услуг и возможностей.

Компонент 4 — Неуклонное совершенствование

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

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

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

Фонд

— Лидерство

В основе Lean лежит лидерство, ключевой фактор успеха команды. Лидеры в конечном итоге несут ответственность за успешное внедрение подхода Lean-Agile. По словам консультанта по вопросам управления и эксперта по эффективности У. Эдвардса Деминга, «такую ​​ответственность нельзя делегировать» [9] прямым подчиненным, сторонникам Lean-Agile, рабочим группам, офису управления программами (PMO), командам процессов, внешним консультантам или любая другая сторона. Следовательно, лидеров необходимо обучать этим новым и инновационным способам мышления и демонстрировать принципы и поведение Lean-Agile лидерства.

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

Дополнительное руководство по лидерству как основе трансформации Lean-Agile с использованием SAFe можно найти в статье о компетенции Lean-Agile Leadership.

Гибкость с помощью Agile Manifesto

В 1990-х годах в ответ на множество проблем, связанных с каскадными процессами, появились более легкие и более итеративные методы разработки.В 2001 году многие лидеры этих фреймворков собрались в Сноуберд, штат Юта. Несмотря на то, что мнения по поводу конкретных преимуществ одного метода перед другим разошлись, участники согласились, что их общие ценности и убеждения затмевают различия. Результатом стал Манифест гибкой разработки программного обеспечения — поворотный момент, который прояснил новый подход и начал предоставлять преимущества этих инновационных методов всей индустрии разработки. [10] За годы, прошедшие с момента первой публикации Манифеста, Agile стали применять в областях, не связанных с разработкой программного обеспечения, включая аппаратные системы, инфраструктуру, операции и поддержку.Совсем недавно бизнес-команды, не связанные с технологиями, также приняли принципы Agile для планирования и выполнения своей работы.

Ценности манифеста Agile

Манифест состоит из заявления ценности, показанного на Рисунке 3:

Рис. 3. Ценности Agile Manifesto

, которые мы ищем лучшие пути

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

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

Где мы находим ценность

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

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

Люди и взаимодействие над процессами и инструментами

Деминг отмечает: «Если вы не можете описать то, что делаете, как процесс, значит, вы не знаете, что делаете». Итак, гибкие процессы в таких фреймворках, как Scrum, Kanban и SAFe, имеют значение.Однако процесс — это только средство для достижения цели. Когда мы зависим от процесса, который не работает, это приводит к потерям и задержкам. Итак, отдавайте предпочтение отдельным людям и взаимодействиям, а затем соответствующим образом изменяйте процессы.

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

Рабочее программное обеспечение поверх исчерпывающей документации

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

Сотрудничество с клиентами в ходе переговоров по контракту

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

Реагирование на изменения в соответствии с планом

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

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

Принципы манифеста Agile

Agile Manifesto, показанный на рисунке 4, содержит 12 принципов, поддерживающих его ценности. Эти принципы продвигают эти ценности на шаг вперед и конкретно описывают, что значит быть Agile.

Рисунок 4. Принципы Agile Manifesto

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

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

Применение манифеста Agile в масштабе

Краткому документу, положившему начало этому массовому движению, более 19 лет. С тех пор ни одно слово не изменилось. Итак, справедливо спросить, учитывая все достижения за последние 19 лет: актуален ли Agile Manifesto? Или его следует рассматривать как исторический документ, который давно выполнил свою задачу?

Более того, Agile был определен для небольших, потенциально быстро меняющихся команд, занимающихся только программным обеспечением. И здесь возникает еще один актуальный вопрос: масштабируется ли Agile Manifesto? Удовлетворяет ли он потребности предприятий, разрабатывающих самое большое и сложное программное обеспечение и системы? Удовлетворяет ли он потребностям систем, для создания которых требуются сотни людей и которые связаны с неприемлемо высокими издержками отказа? А как насчет нетехнических команд на предприятии, которые начинают принимать многие ценности и принципы манифеста? Отзывы от более чем 20 000 организаций, использующих руководство Agile в SAFe, показывают, что Agile Manifesto действительно масштабируется.Однако многие принципы требуют повышенного внимания к масштабу, в то время как другие требуют более широкой перспективы. Agile Manifesto остается актуальным сегодня, как никогда, а может быть, даже в большей степени. Нам повезло, что он есть, и он играет жизненно важную роль в SAFe.

SAFe объединяет ценности и принципы Agile Manifesto во всей структуре. Например, Принципы 1 и 3 описывают частую доставку ценности клиенту. Практики SAFe продвигают доставку как можно чаще (как можно чаще, несколько раз в день), чтобы принести пользу клиенту и обеспечить подтвержденное обучение, которое улучшит будущее развитие.Демонстрация системы SAFe в конце каждой итерации и демонстрация системы PI System и демонстрация решения на каждой границе PI позволяют оценить прогресс на основе рабочих продуктов и компонентов. SAFe объединяет владельцев бизнеса и продуктов, а также менеджеров продуктов и решений для уточнения бэклога, демонстраций, планирования PI, Inspect & Adapt и т. Д., Что демонстрирует его приверженность Принципу 4. Ретроспективы команд, а также мероприятия Inspect & Adapt для ART и решений Поезда, поддержите Принцип 12 Манифеста.Сверху вниз SAFe использует Agile и передовой опыт в масштабах всего предприятия.

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

---

Узнать больше

[1] Двек, Кэрол С. Мышление: новая психология успеха. Издательство Рэндом Хаус. [2] Вомак, Джеймс П., Дэниел Т. Джонс и Дэниел Роос. Машина, изменившая мир: история бережливого производства — секретное оружие Toyota в глобальных автомобильных войнах, революционизирующих мировую промышленность . Свободная пресса, 2007. [3] Уорд, Аллен и Дурвард Собек. Бережливое производство продуктов и процессов . Институт бережливого предпринимательства, 2014 г. [4] Райнертсен, Дональд Г. Принципы разработки продукта: бережливое производство второго поколения . Celeritas, 2009. [5] Поппендик, Мэри и Том Поппендик. Внедрение экономичной разработки программного обеспечения: от концепции к деньгам . Аддисон-Уэсли, 2006. [6] Леффингуэлл, декан. Требования к гибкому программному обеспечению: практика требований бережливого производства для команд, программ и предприятия . Аддисон-Уэсли, 2011. [7] Вомак, Джеймс и Дэниел Джонс. Lean Thinking: Banish Wast e и создайте богатство в своей корпорации. Свободная пресса, 2003. [8] Accelerate: отчет о состоянии DevOps за 2018 год. http://services.google.com/fh/files/misc/state-of-devops-2018.pdf [9] Деминг, У. Эдвардс. Выйти из кризиса. MIT Center for Advanced Educational Services, 1982. [10] Манифест для гибкой разработки программного обеспечения. http://AgileManifesto.org/

Последнее обновление: 21 апреля 2021 г.

Информация на этой странице принадлежит © 2010-2021 Scaled Agile, Inc. и защищена американскими и международными законами об авторских правах.Ни изображения, ни текст не могут быть скопированы с этого сайта без письменного разрешения правообладателя. Scaled Agile Framework и SAFe являются зарегистрированными товарными знаками Scaled Agile, Inc. Посетите раздел часто задаваемых вопросов о разрешениях и свяжитесь с нами для получения разрешений.

Agile: простота — искусство максимизировать работу, которую не делают

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

В этом посте мне нравится делиться тем, что я понял и собрал из моего общения с этими людьми: Стив Эш, Чарльз Брэдли, Линн Шрусбери, Рууд Ритвельд, Филип Леджервуд, Джон Хебли, Джефф МакКенна, Джордж Динвидди, Адам Срока, Майкл Джеймс. , Мэтт Андерсон и Кэсс Далтон.

Простота — это высшая изощренность. ~ Леонардо да Винчи

Разгрузка — следствие простоты. Простота приводит к:

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

Скрам-философия работы в небольших командах, небольших спринтах, небольших историях, впитывающих простоту мышления — продуманное сокращение.

Желательность простоты иногда выражается как принцип KISS.

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

Спасибо Скотту Амблеру за то, что поделился этим термином JBGE. Вы можете прочитать об этом больше в моей предыдущей публикации Agility — это о выявлении и достижении «достаточно хорошего»

Есть момент, когда любые дополнительные усилия, приложенные к рабочему продукту, увеличивают его стоимость без увеличения его стоимости. Если не ноль, увеличение стоимости может быть незначительным по сравнению с увеличением стоимости.Это момент, чтобы остановиться! (Достижение JBGE).

Легко продолжить разработку продукта после определенного момента. Исследование Standish Group в 2009 году показало, что более 70% функциональных возможностей никогда не используются или используются редко. Отказ от этой работы — прекрасная возможность заниматься более ценной работой.

Самый простой способ добиться простоты — продуманное сокращение. Вдумчивое сокращение увеличивает объем незавершенной работы. Тщательный осмотр, чтобы удалить отходы процесса и продукта.

Несколько примеров Agile-мышления и практик, которые приходят мне в голову:

• Разработка через тестирование следует за простотой .У вас достаточно кода, чтобы пройти ваши тесты. Определяя сначала меру успеха, а затем кодируя ее (и только потом), вы избавляетесь от большого количества ненужной работы.
• Building рабочего программного обеспечения ровно столько, чтобы получить обратную связь .
• Написание документации ровно столько, чтобы удовлетворить потребность.
• Использование карточек историй (Как клиент я хочу что-то сделать, чтобы получить какую-то ценность). Вы ничего не делаете, если ценность не может быть четко указана.
• Использование простых досок для задач для измерения прогресса.
• Уточнение бэклога : Владелец продукта убирает бэклог, чтобы определить функции, которые сделают его продукт успешным. Проверьте мой предыдущий пост Владелец продукта Scrum должен поцеловать много лягушек, чтобы найти принца
• Наличие всего 3 ролей в Scrum (команда, ScrumMaster и владелец продукта) в команде — это простота.
• Продуманное сокращение иерархии внутри организации — шаг к простоте.

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

XP-term «YAGNI» («Тебе это не понадобится») определяет простоту. Команды хотят создавать больше, чем требуется, потому что нам это понадобится в будущем. Но вскоре дорога может пойти в другом направлении, и тогда вся работа будет потрачена зря. Поэтому лучше сделать это сейчас просто и украшать только тогда, когда это действительно необходимо.

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

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

• Предоставляет функции, о которых никто не просил.
• Золочение вещей, которые уже готовы к отправке.

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

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

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

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