Agile это: методология, метод или философия? — статья в блоге ScrumTrek

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

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

Роли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Риски

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

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

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

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

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

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

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

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

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

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

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

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

или

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

или

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исходник — Agile Product Ownership in a nutshell

видео на английском

видео на русском

Что такое agile, scrum, kanban и в чем разница?

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Agile, scrum, kanban: в чем разница и для чего использовать?

Светлана Зыкова

Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

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

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

(Из перевода колонки Forbes на Rusbase)

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.
Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач.
Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте.
Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.
Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.
Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.
Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.
Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.
Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.
Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский
Директор по технологии в онлайн-кинотеатре ivi

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

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Что почитать по теме?

1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
5. K. Schwaber, J. Sutherland “The Scrum Guide”
6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Cover photo by Daria Nepriakhina on Unsplash

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

Что такое Agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile. 

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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

Основные принципы Agile

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

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

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

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

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

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

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

Большая часть этой документации не несет также и ценности клиенту! Сначала создайте продукт, а потом документируйте его.

Ценность 3. Сотрудничество с заказчиком важнее согласования условий контракта

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

Ценность 4. Готовность к изменениям важнее следования первоначальному плану

Из этой формулировки следует миф о том, что в Agile нет планирования. Это неверно. Гибкие подходы создавались для условий неопределенности и частых изменений. Предварительное планирование, то есть подход, когда мы сначала долго планируем проект, распределяем ресурсы и задачи, не работает.

Конечно, оно несет определенную пользу, но приоритет отдается планированию оперативному. Как правило, горизонт детального планирования задач составляет 2-4 недели. Если все вокруг меняется часто — ваши планы тоже должны.

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

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

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

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

Итеративный и итеративно-инкрементальный подходы. Автор иллюстрации Jeff Patton

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

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

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

Закон Парето гласит, что 20% усилий дают 80% результата. Иногда даже этих 80% нашего бэклога бывает достаточно для нас или нашего заказчика.

Чем Agile отличается от Scrum

Scrum — термин из регби, по-русски — схватка. Название подходу придумал Кен Швабер, один из авторов Скрама и фанат регби. Судя по всему, количество игроков и то, как они всей командой собираются вокруг мяча, напомнило ему команду, работающую по Скраму. Кен Швабер и Джефф Сазерленд создали Скрам в 90-е (а через почти 10 лет участвовали в написании Agile-манифеста). 

Так выглядит Скрам в регби

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

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

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

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

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

Сложность продукта может происходить из:

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

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

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

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

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

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

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

Источник: VersionOne State of Agile 13 Annual Report

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

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

Примеры проектов и применение Agile

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

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

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

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

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

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

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

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Инструменты Agile

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

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

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

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

Существует множество цифровых аналогов этих инструментов с впечатляющим функционалом. Однако при перемещении красочных досок и флипчартов с графиками в диджитал-пространство обычно теряется эффект «радиации» информации.

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

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

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

Плюсы Agile

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

Источник: Отчет об исследовании Agile в России 2019

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

Источник:  2015 CHAOS report from the Standish Group

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

Минусы Agile

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

Некоторые организации очень беспокоят такие издержки. Их можно снизить, если создать для команды условия, в которых она сможет быстро и как можно менее болезненно ошибаться согласно неофициальному девизу Agile «Fail Fast — Fail Safe» («Ошибайся как можно раньше — ошибайся безопасно»). Однако такие структуры и среды также стоят дорого. 

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

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

Как внедрить

Agile нельзя внедрить. Agile — это трансформация процессов и культуры организации. 

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

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

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

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

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

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

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

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

Резюме

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

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

Фото на обложке: Shutterstock / Den Rise

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

Agile-трансформация и роль топ-менеджмента

25 Июл 2019

В рубрике HowTo консалтинговая компания Boston Consulting Group (BCG) объясняет, как правильно настроить Agile в организации со ссылками на их другие статьи по agile: все начинается – или заканчивается – на уровне руководства. Ключ к изменению того, как работает компания – это изменение того, как думает, работает и руководит топ-менеджмент.

Что вам необходимо знать об agile

Agile – это итеративный, кросс-функциональный, ориентированный на команду подход, который можно применять в любой отрасли и разных бизнес-условиях. Первоначально появившийся в области разработки программного обеспечения, agile ставит на первое место скорость, автономность и совместную работу для того, чтобы раскрыть полный потенциал организаций. К основным выгодам, которые дает agile, относят снижение издержек на 25-35%, улучшение качества на 20% и ускорение создания новых продуктов и услуг на 100-200%. Подробнее о выгодах можно прочитать в другой статье (на английском) — Измерение эффекта от agile – на bcg.com

Agile трансформация начинается с изменения образа мышления

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

Как рассказывает Мартин в выступлении, при проведении Agile-трансформации в крупном банке, они изучили опыт Google, Netflix, Spotify, Zappos и начали менять жесткую иерархию банка на подходы современных компаний, то есть формировать междесцилинарные команды. Они раскидали маркетологов, инженеров и других сотрудников, сидящих вместе по подразделениям, в продуктовые команды, всего 3 тыс. человек были рассажены по 350 командам. И самым сложным в такой истории является изменение мышление руководства, поскольку меняется их роль, команды сами начинают лидировать и задача руководителей заключается в помощи, а не лидерстве…

Видео — https://youtu.be/OWiiA9hXbY8

Agile-трансформация требует приверженности со стороны высшего руководства

75% усилий, направленных на трансформации, не достигают своих целей в терминах получаемой ценности, сроков, или и того, и другого.
Большинство крупных организаций выстроены из отдельных подразделений и специализированных функций. Это создает источник неэффективности, который можно устранить, используя гибкие подходы. Чтобы применять agile во всей организации, командам нужно научиться работать по-другому на всех уровнях. Об основных ловушках, которых нужно избегать при трансформации можно прочитать в другой статье BCG (на английском) — Ловушки, которых нужно избегать – на bcg.com

Agile-лидерство означает дать свободу

Некоторые руководители беспокоятся, что гибкие подходы к работе могут означать потерю контроля и, неизбежно, хаос для их компаний. Но речь не о контроле работы. Agile – это про вдохновение на изменения в поведении.
Для agile-лидеров самая важная задача – четко описать желаемый результат и дать командам возможность работать автономно для достижения этого результата. Концентрация на цели – «почему?» организации – помогает лидерам отступить назад и дать свободу действий командам. Команды в свою очередь будут двигаться вперед, а бизнес – развиваться. Про agile-лидеров можно прочитать в другой статье (на английском) — Есть ли у вас смелось быть agile-лидером – на bcg.com

Успешное внедрение agile в организации начинается с изменения привычных методов работы высшего руководства. Необходимо принять гибкий образ мышления, разделять ценности и принципы гибких подходов. Жесткая иерархическая структура организации – это препятствие для работы по agile. Эксперты BCG предлагают 5 шагов, которые помогут высшему руководству поддерживать ход agile-трансформации. Один из главных тезисов – не бояться потерять контроль над работой, так как перед командой сформулирована четкая бизнес-цель.

Мария Белых, ведущий консультант, PRINCE2 Practitioner, ICAgile Certified Professional
Источник: https://www.bcg.com/featured-insights/how-to/agile.aspx

Смотрите также:
• Сертификационный тренинг по agile в Москве
• Почему agile работает
• Новая версия руководства Domains of Business Agility

Agile – это ошибка

1. Создание IT-продуктов для широких масс

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

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

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

P.S. Кроме итераций, иногда вам могут помочь инкременты. И это таки две большие разницы.

2. Тестирование гипотез или создание MVP

Тестирование гипотез – это вообще прикольно, полезно и интересно. Для некоторых ещё и крайне познавательно. Agile в данном случае помогает это сделать быстро и дёшево (и это, кстати, то, что от меня редко слышат люди: что Agile – это дёшево).

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

Примеров – тысячи. И даже те самые лендинги на Тильде, которые делают наши предприниматели, прежде чем пытаться что-то продать (два в одном – и гипотезу протестировали, и MVP сайта).

Внезапно, если у вас уже контракт на всю работу – вряд ли это стоит называть MVP. Ну просто потому, что от него решение Go/No go уже не зависит.

3. Создание продуктов или реализация проектов в постоянно меняющейся среде

Важно! Это редко когда создание информационных систем при наличии ТЗ и нормативки.

Почему? Даже не из-за снижения затрат на планирование (неожиданно, но в классическом Project-менеджменте есть такие инструменты как Rolling wave planning, а ещё короткие циклы перепланирования), а из-за восприятия данного перепланирования людьми. В этом есть какая-то магия, но изменить бэклог проще, чем изменить план, даже очень короткий.

В общем-то, это почти как первый пункт, но только не для широких масс. Ну например, делали вы приложение, которое планировалось работать с 1С и «внезапно» заказчик ушёл на SAP (очень внезапно, за годик-два, сарказм).

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

4. Реализация НИРов

Возможно, это спорно. Я долго думал, выделять ли этот пункт (ведь это можно рассматривать как гипотезу или MVP), но решил, что всё же НИР –это шире, и оно того стоит.

Нет, НИР тоже планируют. Но я почему-то вижу, что когда у людей ПЛАН (именно так), то они редко когда останавливаются, если внезапно, на ранних этапах они достигают успеха. Они видят своей целью проверить всё, что есть в плане, и это ведёт к потерям времени и денег, если там нет человека, который адекватно видит задачу (и многие там – натуры увлечённые). А может быть, не столько увлечённые, сколько переживающие за свои рабочие места?

У меня будет не совсем научный пример, но он тонко намекнёт, откуда растут ноги. Клиент искал подходящую железку. Подошла первая же. Причём как по цене, так и по параметрам (избыточным, к слову). НО… Сотрудники пошли проверять ещё 2 и потеряли на этом больше месяца. Потому что им сказали посмотреть «штуки три».

Так вот, при отсутствии формального плана quick win воспринимается проще. И я уже говорил, что, на мой взгляд, это какая-то магия?

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

А теперь – ошибки.

Академия | Agile-трансформация в Сбербанке

По следам конференции «Команды-2017. Опыт лидеров», которая прошла 29 ноября и на которой побывала Юлия ЧемеринскаяСамое практическое и конкретное выступление было у Наталии Даниленко, начальника управления по работе с персоналом Сбербанк Технологии. О нем и напишу. Ибо масштаб сберджайлизации абсолютно уникален для России: сейчас в agile-­периметре уже более 11000 сотрудников группы компаний Сбербанк, из них более 6000 — это сотрудники ИТ-компании, в которой Наталия является руководителем HR-службы. 

Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)
 

КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ

Манифест — манифестом, его уже все выучили:)
А вот конкретные цели. Чего в компании хотели достичь:

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

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

Разумеется, возникает вопрос: при размывании роли руководителей как оно все управляется? И что сказали боссы, которых лишили должностей и званий? Сняли, так сказать, погоны? Отвечу сначала на второй вопрос. Разговоров пришлось провести много. Но теперь в подразделениях Сбербанка, перешедших в agile, больше нет отделов, управлений и департаментов в штатном расписании. Бывшие начальники отделов, управлений, департаментов теперь на экспертных должностях без подчиненных.  Трайб — это организационный «мешок» в котором нет больше иерархической структуры и начальников.
Кстати, никто из них не уволился! В отличие от, к примеру, переходящего на холакратию Zappos, который потерял 50% своих менеджеров, не согласных с таким поворотом:)

УПРАВЛЕНИЕ В СБЕРДЖАЙЛ

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

1. Владелец продукта.

 
С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель – сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.

2 и 3. Лидер чаптера и Лидер компетенции

Лидер чаптера — это такой играющий тренер. У него 7 человек. На 50% он является лидером чаптера, а на 50% занимается  развитием других. Например, у него 15-летний опыт работы с кредитными картами. Он и создает с командой продукт, и развивает сотрудников в других командах, кто тоже занимается кредитеыми картами.

Лидер области компетенций, к примеру, мастер 80-го уровня в IOS, занимается только развитием этой техкомпетенции у 24 сотрудников, за которых он отвечает. Грубо говоря, учит писать и проверяет их IOS-коды.

4. Agile-коуч

От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.

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

ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ

Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.
Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.

То есть одним человеком на постоянной основе занимаются аж сразу три человека:

• владелец продукта смотрит на него с позиции создания самого продукта — качества и сроков,
• лидер компетенции — на его технические компетенции,
• аgile-коуч отвечает за его развитие в эджайл, его роли в команде, его потенциала.

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

ПРЕМИРОВАНИЕ

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

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

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

Ну и в заключении плюсы и минусы.

ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ

МИНУСЫ AGILE-ТРАНСФОРМАЦИИ

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

Если вам было интересно, ставьте лайки и делитесь постом, буду писать еще.
Удачи,
Ваша Чемеринская
[email protected]

Что такое Agile: методология или философия? :: РБК Pro

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

Фото: Andreas Rentz / Getty Images

Agile — философия, Scrum — ее реализация

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

Agile манифистирует:

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

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

Четыре ценности Agile: «X важнее Y»

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

, что это такое, как это работает и почему это круто

Фреймворк

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

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

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

Артефакты Scrum

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

• Журнал невыполненных работ по продукту — это основной список работ, которые необходимо выполнить, и ведется владельцем продукта или менеджером продукта. Это динамический список функций, требований, улучшений и исправлений, который используется в качестве входных данных для бэклога спринта.По сути, это список дел команды. Бэклог продукта постоянно пересматривается, меняет приоритеты и поддерживается Владельцем продукта, потому что по мере того, как мы узнаем больше или по мере изменения рынка, элементы могут перестать быть актуальными или проблемы могут быть решены другими способами.
• Журнал спринта — это список элементов, пользовательских историй или исправлений ошибок, выбранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом, на собрании по планированию спринта (которое мы обсудим позже в этой статье) команда выбирает, над какими элементами она будет работать в спринте из бэклога продукта.Бэклог спринта может быть гибким и может развиваться во время спринта. Однако фундаментальная цель спринта — то, чего команда хочет достичь в текущем спринте, — не может быть нарушена.
• Приращение (или цель спринта) — это полезный конечный продукт спринта. В Atlassian мы обычно демонстрируем «приращение» во время демонстрации в конце спринта, где команда показывает, что было выполнено в ходе спринта. Возможно, вы не услышите слово «приращение» в мире, поскольку его часто называют определением команды «Готово», вехой, целью спринта или даже полной версией или отправленным эпиком.Это просто зависит от того, как ваша команда определяет «Готово» и как вы определяете свои цели в спринте. Например, некоторые команды предпочитают выпускать что-то для своих клиентов в конце каждого спринта. Таким образом, их определение «готово» будет «отправлено». Однако это может быть нереально для других типов команд. Допустим, вы работаете над серверным продуктом, который может поставляться вашим клиентам только раз в квартал. Вы по-прежнему можете работать в двухнедельных спринтах, но ваше определение «готово» может быть завершением части большой версии, которую вы планируете выпустить вместе.Но, конечно, чем больше времени уходит на выпуск программного обеспечения, тем выше риск того, что оно не попадет в цель.

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

Церемонии или события Scrum

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

Ниже приведен список всех ключевых церемоний, в которых может принять участие scrum-команда:

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

2. Планирование спринта : Работа, которая будет выполнена (объем) в течение текущего спринта, планируется во время этой встречи всей командой разработчиков.Это собрание проводится мастером схватки, и именно на нем команда определяет цель спринта. Затем в спринт добавляются истории конкретного использования из бэклога продукта. Эти истории всегда соответствуют цели, а также согласовываются с командой scrum, чтобы их можно было реализовать во время спринта.

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

3. Спринт : Спринт — это фактический период времени, когда команда схватки работает вместе, чтобы завершить приращение.Две недели — довольно типичная продолжительность спринта, хотя некоторые команды считают, что неделю легче охватить, а месяц легче обеспечить ценный прирост. Дэйв Уэст из Scrum.org советует, что чем сложнее работа и чем больше неизвестных, тем короче должен быть спринт. Но это действительно зависит от вашей команды, и вы не должны бояться ее менять, если она не работает! В течение этого периода объем может быть повторно согласован между владельцем продукта и командой разработчиков, если необходимо. Это составляет суть эмпирической природы схватки.

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

4. Ежедневная схватка или стоя : это ежедневная сверхкороткая встреча, которая проводится в одно и то же время (обычно утром) и место, чтобы не усложнять задачу. Многие команды стараются завершить собрание за 15 минут, но это всего лишь ориентир.Эту встречу также называют «ежедневной стойкой», подчеркивая, что она должна быть быстрой. Цель ежедневной схватки — чтобы все в команде были на одной странице, согласованы с целью спринта, и разработали план на следующие 24 часа.

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

   Обычно каждый член команды отвечает на три вопроса в контексте достижения цели спринта:

   • Что я делал вчера?
   • Что я планирую делать сегодня?
   • Есть ли препятствия?

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

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

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

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

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

Скрам-команде нужны три определенные роли: владелец продукта, мастер схватки и команда разработчиков. А поскольку команды scrum кросс-функциональны, в команду разработчиков помимо разработчиков входят тестировщики, дизайнеры, специалисты по UX и операционные инженеры.

Владелец продукта схватки

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

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

Мастер схватки

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

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

Команда разработчиков Scrum

Команды Scrum добились успеха.Они являются лидерами практики устойчивого развития. Самые эффективные команды схватки — сплоченные, расположенные в одном месте, обычно от пяти до семи человек. Один из способов определить размер команды — использовать знаменитое «правило двух пицц», придуманное Джеффом Безосом, генеральным директором Amazon (команда должна быть достаточно маленькой, чтобы разделить две пиццы).

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

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

Scrum, kanban и agile

Scrum — это настолько популярная гибкая среда, что scrum и agile часто неправильно понимаются как одно и то же.Но есть и другие фреймворки, например, канбан, который является популярной альтернативой. Некоторые компании даже предпочитают следовать гибридной модели схватки и канбана, получившей название «Scrumban» или «Kanplan», то есть Kanban с отставанием.

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

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

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

Но почему схватки?

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

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

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

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

Изучите Scrum с помощью Jira Software

Scrum tutorial

В этом руководстве мы дадим вам пошаговые инструкции о том, как управлять проектом Scrum, расставить приоритеты и организовать ваше отставание в спринты, запустить scrum церемонии и многое другое — все в Jira Software.

Время:

Чтение за 10 минут. Завершить за 2 недели

Аудитория:

Вы новичок в scrum, гибкой разработке программного обеспечения или Jira Software

Предварительное условие:

Вы создали учетную запись Jira Software

Получить бесплатно

Что такое scrum?

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

Шаг 1. Создание проекта Scrum

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

В качестве альтернативы, если вы ищете более простой и понятный интерфейс, попробуйте наш шаблон Scrum нового поколения.Дополнительные сведения см. В разделе «Начало работы с проектами нового поколения» в сообществе Atlassian.

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

Шаг 2. Создание пользовательских историй или задач в журнале очереди

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

Что такое пользовательские истории?

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

Давайте использовать веб-сайт в качестве простого примера для создания пользовательской истории.

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

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

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

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

Шаг 3. Создайте спринт

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

Что такое спринт?

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

Шаг 4: Проведите собрание по планированию спринта

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

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

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

Что такое собрание по планированию спринта?

Участники: Требуется: команда разработчиков, мастер схватки, владелец продукта

Когда: В начале спринта.

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

Цель: Спланировать работу спринта. Команда соглашается с целью спринта и отставанием в спринте.

Что такое цель спринта?

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

Что такое гибкая оценка?

Традиционные команды разработчиков программного обеспечения дают оценки в формате времени: дни, недели, месяцы.
Однако многие agile-команды перешли на очки истории. Story points оценивают относительное усилие работы, часто в формате, подобном Фибоначчи: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

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

Шаг 5. Запустите спринт в Jira

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

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

Добавьте цель спринта, как было согласовано на собрании по планированию спринта.

После запуска спринта вы попадете на вкладку «Активные спринты» в проекте.

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

Если вы используете шаблон Scrum следующего поколения, он будет называться Board .

Шаг 6: Ежедневно проводите стандартные встречи

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

Что такое ежедневная стендап-встреча?

Участники (в основном): команда разработчиков

Когда: Один раз в день, обычно утром

Продолжительность: Не более 15 минут. Не бронируйте конференц-зал и не проводите стендап сидя. Если встать, встреча будет короткой!

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

• Что я выполнил вчера?
• Над чем я буду работать сегодня?
• Я чем-нибудь заблокирован?

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

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

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

Шаг 7: Просмотр диаграммы выгорания

Рекомендуется проверять диаграмму выгорания во время спринта.В Jira Software диаграмма Burndown Chart показывает фактический и предполагаемый объем работы, которую необходимо выполнить за спринт. Диаграмма выгорания автоматически обновляется Jira по мере выполнения рабочих элементов. Чтобы просмотреть эту диаграмму, нажмите «Отчеты» на боковой панели, а затем выберите «Burndown Chart» в раскрывающемся списке отчетов.

Что такое Burndown Chart и как вы его читаете

Burndown Chart показывает фактический и предполагаемый объем работы, которую нужно выполнить за спринт. Горизонтальная ось X на диаграмме Burndown Chart указывает время, а вертикальная ось Y обычно указывает точки истории.

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

Анти-паттерны, за которыми нужно следить.

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

Шаг 8: Просмотр отчета о спринте

В любой момент во время или после спринта вы можете просмотреть отчет о спринте, чтобы отслеживать спринт.

Что такое отчет о спринте?

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

Шаг 9: Проведите собрание по обзору спринта

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

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

Участники (в основном): команда разработчиков , мастер схватки, владелец продукта.
Дополнительно: заинтересованных сторон

Когда: Обычно в последний день спринта

Продолжительность: Обычно два часа для двухнедельного спринта

Цель: Проверить приращение и совместно обновлять список невыполненных работ по продукту.

Вопросы:

• Выполнила ли команда прогноз на спринт?
• Были ли добавлены или удалены работы в середине спринта?
• Не удалось ли выполнить какую-либо работу за спринт?
• Если да, то почему?

Шаг 10: Проведите ретроспективное собрание спринта.

После завершения спринта попросите свою команду провести ретроспективу.Задокументируйте свою ретроспективу где-нибудь. Мы можем предложить Confluence?

Что такое ретроспективная встреча спринта?

Участники: команда разработчиков, scrum-мастер, product owner.

Когда: В конце итерации.

Продолжительность: Обычно 90 минут для двухнедельного спринта.

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

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

Вопросы:

• Что у нас было хорошо во время спринта?
• Что мы могли сделать лучше?
• Что мы будем делать лучше в следующий раз?

ProTip: Даже если дела в команде идут хорошо, не прекращайте проводить ретроспективы.Ретроспективы служат постоянным ориентиром для команды, чтобы дела шли хорошо.

Шаг 11: Завершите спринт в Jira

В конце спринта вы должны его завершить.

Если в спринте есть неполные задачи, вы можете:

• Переместить проблему (и) в очередь.
• Перенести проблемы в будущий спринт.
• Перенесите задачи в новый спринт, который Jira создаст для вас.

Шаг 12: Повторите с шага 2

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

После того, как вы и ваша команда освоите описанные выше шаги. Перейдите к расширенной статье: Как выполнять расширенные методы схватки с Jira Software.

Клэр Мейнард

Клэр — ветеран маркетинга Atlassian, которая на протяжении всего срока своего пребывания в должности занималась вопросами роста, повышения эффективности и маркетинга продуктов. В настоящее время она управляет брендом, контентом и маркетинговой стратегией для Confluence Cloud.Вне работы вы можете найти Клэр, которая занимается серфингом, бегает или пробует новые рестораны в Сан-Франциско или новых городах по всему миру.

Что такое AGILE? — Что такое SCRUM? — Agile FAQ’s

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

ScrumMaster

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

• Научите владельца продукта, как максимизировать рентабельность инвестиций (ROI) и достичь его / ее целей с помощью Scrum.
• Улучшите жизнь команды разработчиков, способствуя творчеству и расширению возможностей.
• Повысьте продуктивность команды разработчиков любым возможным способом.
• Усовершенствуйте инженерные практики и инструменты, чтобы каждый дополнительный функционал можно было отгрузить.
• Держите информацию о прогрессе команды в актуальном состоянии и видимой для всех сторон.

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

Загрузите шпаргалку по ролям Scrum Master

Владелец продукта

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

Загрузить шпаргалку по роли владельца продукта

Команда

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

Загрузить Шпаргалку по Scrum Team

Интеграция Agile & Scrum разработки и методологии

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

Шаян Алам, PMP

Методологии разработки

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

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

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

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

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

5 советов по интеграции групп разработки Agile и scrum с группами разработки водопада

Попытка внедрить Agile как итеративный водопад не сработает

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

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

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

Остерегайтесь ползучести прицела

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

Играйте спокойно с QA

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

Помните о конечном пользователе

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

Если вам нужна дополнительная информация по этой теме, отправьте электронное письмо по адресу [электронная почта защищена]. Мы приветствуем ваши вопросы, комментарии и отзывы.

Другие часто просматриваемые статьи

Часто задаваемые вопросы по гибкой разработке программного обеспечения с использованием Scrum: узнайте об гибкой разработке программного обеспечения, Scrum, историях, ролях и многом другом…

Agile, Waterfall и неопределенность в управлении проектами: Agile Development vs. Waterfall

Введение в Scrum: преимущества и методы гибкой разработки программного обеспечения с помощью Scrum.

Scrum как управление проектами: сравнение и контрастирование Agile Development Scrum с традиционными методологиями управления проектами.

Agile Development & Scrum соответствует PMP: Agile Development, ее сравнение и отличие от методологии PMI.

ежедневных схваток в распределенном мире: формальное сотрудничество для сокращения накладных расходов.

Интеграция Waterfall и Agile Development: советы по интеграции методологий Waterfall и Agile Development.

3 различия между Scrum и Kanban, которые необходимо знать

Столбцы

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

Вкратце, что такое Scrum?

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

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

Еще один распространенный инструмент, используемый Scrum-командами, — это Scrum Board — визуальное представление рабочего процесса, разбитого на управляемые блоки, называемые «историями», причем каждая история перемещается по доске из «backlog» (списка дел). , в незавершенное производство (WIP) и на завершение.

Вкратце, что такое Канбан?

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

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

Как скрам и канбан — одно и то же?

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

Чем отличаются Scrum и Kanban?

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

Планирование, итерация и частота кадров

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

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

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

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

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

Роли и обязанности

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

Сама команда scrum также должна быть кросс-функциональной, то есть одна команда должна иметь все ресурсы, необходимые для выполнения всей работы спринта.

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

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

Сама плата

Хотя Scrum Board и Kanban Board очень похожи, это разные животные.

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

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

Что лучше для ваших нужд?

На самом деле нет возможности ответить на этот вопрос в этой статье.

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

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

Информацию о вариантах обучения Kanban и Scrum см. Ниже, где представлены курсы, предлагаемые Cprime Learning.
Kanban Workshop
Сертифицированный ScrumMaster Workshop (CSM)
Certified Scrum Product Owner (CSPO) Workshop
Advanced Certified ScrumMaster (A-CSM)

Другие ресурсы, которые могут вас заинтересовать, включают:

Статья: Подходит ли мой проект для Kanban или Scrum?

FAQ: что такое Agile, что такое Scrum

Вебинар: что можно делать с Канбан

Узнайте больше о Scrum и Kanban: Посетите нашу полную библиотеку ресурсов

Получите полный обзор Agile и Scrum

Погрузитесь и узнайте больше

Кэссиди Найт, писатель по Agile-техническим вопросам

Что такое Agile и почему это важно?

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

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

Что такое Agile?

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

Origins of Agile

Термин Agile появился довольно давно. Его можно проследить до латинского термина agilis , что означает «ловкий или быстрый», и от термина agere , что означает «приводить в движение или сохранять движение».

Итак, , что такое Agile ? Современное использование гибкой разработки в качестве метода работы можно проследить до 2001 года, когда в Сноуберд, штат Юта, прошла встреча лидеров мнений по разработке программного обеспечения. Эти идейные лидеры встретились, чтобы обсудить, как улучшить разработку программного обеспечения.

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

Лидеры мнений в области разработки программного обеспечения работали над различными альтернативными подходами к разработке, такими как экстремальное программирование, Crystal и Scrum. Неофициально эти подходы назывались легковесными методами, в отличие от предыдущих «тяжелых» методов.

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

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

Но Agile Manifesto остается основным кредо группы.

Манифест гибкой разработки программного обеспечения — 4 ценности и 12 принципов

Давайте внимательнее рассмотрим 4 ценности Agile и 12 принципов, лежащих в основе манифеста Agile.

4 значения Agile в манифесте

На приведенном ниже рисунке с веб-сайта Agile Manifesto показаны четыре утверждения Agile Value.

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

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

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

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

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

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

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

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

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

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

Все эти ценности в Манифесте важны, но элементы слева имеют более высокий приоритет, чем элементы справа.

12 принципов Agile

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

Для удобства я пронумеровал 12 принципов, но на веб-сайте они просто перечислены без цифр.

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

Второй принцип — приветствовать изменение требований даже на поздних стадиях разработки.В то время, когда это было написано, большинство людей были сосредоточены на контроле изменений или управлении «расширением масштабов». [Посмотрите, почему я считаю, что Scope Creep — ерунда.]

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

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

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

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

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

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

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

Принцип номер семь — рабочее программное обеспечение — это основной показатель прогресса. Традиционно процент завершения использовался для измерения прогресса проектов. Процент выполнения очень ненадежен, потому что людям сложно определить процент, особенно когда он достигает 80 или 90%. Редко когда сделано 90% означает, что осталось только 10% усилий или времени. [Более подробная информация о правиле 90% приведена в разделе «Почти готово».]

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

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

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

Побочным эффектом предпочтения личного общения является то, что имеет смысл объединять людей, которые находятся в одной agile-команде.Многие организации сегодня игнорируют то, что кажется здравым смыслом — см. «Насколько важно совместное размещение Agile-команд».

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

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

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

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

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

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

Научный менеджмент и сборочная линия

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

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

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

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

Основные принципы гибкой разработки

Разработка

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

# 1 — All One Team

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

# 2 — Сотрудничество команды и клиента

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

# 3 — Ограниченные по времени итерации

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

# 4 — Примите изменения

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

# 5 — Расширяйте возможности и доверяйте командам

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

# 6 — Непрерывное совершенствование

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

# 7 — Устойчивый темп

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

У Джимми Дженлена есть видео, объясняющее эти различия, которые я рекомендую. Это называется «Краткое объяснение Agile».

Agile стал универсальным термином

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

К наиболее популярным используемым сегодня фреймворкам относятся Scrum, XP, Kanban и гибриды. Есть и другие, и многие фреймворки вышли из моды с годами, в том числе:

• Разработка на основе функций
• Разработка на основе поведения
• Crystal
• Экономичная разработка программного обеспечения
• Метод динамической разработки программного обеспечения
• Гибкая разработка программного обеспечения

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

Почему Agile имеет значение

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

Agile против гибкости

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

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

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

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

Ключевые преимущества гибкой разработки

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

• 88% людей, которые ответившие на опрос сказали, что они лучше справляются с изменением приоритетов
• 83% респондентов заявили, что они испытали повышение производительности команды
• 83% также указали на улучшение видимости проекта
• 81% респондентов указали повышение морального духа и мотивации команды
• Ускорение вывода на рынок на 81%

Еще одним важным преимуществом, не включенным в вышеприведенный опрос, были показатели успешности проектов.Standish Group отслеживает успехи и неудачи ИТ-проектов с 1994 года. В недавнем исследовании Standish Group, включавшем данные 4000 проектов с 2013 по 2017 год, они обнаружили, что гибкие подходы в 2 раза более успешны, чем водопадные / традиционные подходы и традиционные проекты. были в 3 раза чаще провалились или были отменены.

Ключевые преимущества гибкости

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

• Повышение конкурентоспособности
• Доставляет удовольствие клиентам
• Инновации и более быстрое внедрение изменений
• Привлекайте и удерживайте высокопроизводительных сотрудников

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

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

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

Резюме — Что такое Agile и почему это важно

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

Обнимая Agile

Вкратце об идее

Проблема

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

Первопричина

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

Решение

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

Гибкие методы инноваций произвели революцию в информационных технологиях.За последние 25–30 лет они значительно увеличили показатели успеха в разработке программного обеспечения, улучшили качество и скорость вывода на рынок, а также повысили мотивацию и производительность ИТ-команд.

Сейчас гибкие методологии, включающие новые ценности, принципы, практики и преимущества и являющиеся радикальной альтернативой командно-административному управлению, распространяются в широком диапазоне отраслей и функций и даже в топ-менеджеры. Национальное общественное радио использует гибкие методы для создания новых программ.John Deere использует их для разработки новых машин, а Saab — для производства новых истребителей. Intronis, лидер в сфере облачных сервисов резервного копирования, использует их в маркетинге. C.H. Робинсон, глобальный сторонний поставщик логистических услуг, применяет их в человеческих ресурсах. Винодельня Mission Bell использует их для всего: от производства вина до складирования и управления группой высшего руководства. И GE полагается на них, чтобы ускорить широко разрекламированный переход от конгломерата 20-го века к «цифровой промышленной компании» 21-го века. Выделяя людей из их функциональной разрозненности и помещая их в самоуправляемые и ориентированные на клиента междисциплинарные команды, гибкий подход не только ускоряет прибыльный рост, но и помогает создать новое поколение квалифицированных генеральных менеджеров.

Распространение гибкости открывает интригующие возможности. Что, если бы компания могла добиться положительной прибыли, увеличив на 50% внедрение новых продуктов? Что, если бы маркетинговые программы могли генерировать на 40% больше запросов клиентов? Что, если бы человеческие ресурсы могли нанять на 60% больше своих первоочередных задач? Что, если бы вдвое больше рабочих было эмоционально вовлечено в свою работу? Agile привнесла такие улучшения в ИТ. Возможности в других частях компании значительны.

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

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

Дополнительная литература

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

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

1. Узнайте, как на самом деле работает Agile

Некоторые руководители, кажется, ассоциируют agile с анархией (каждый делает то, что хочет), в то время как другие считают, что это означает «делать то, что я говорю, только быстрее».«Но Agile — ни то, ни другое. (См. Врезку «Ценности и принципы Agile».) Он бывает нескольких разновидностей, которые имеют много общего, но подчеркивают несколько разные вещи. Они включают схватку , , которая подчеркивает творческую и адаптивную командную работу при решении сложных проблем; бережливое развитие, фокусируется на постоянном устранении отходов; и канбан, , которые сосредоточены на сокращении времени выполнения заказа и объема незавершенной работы. Один из нас (Джефф Сазерленд) помогал разработать методологию схватки, и на это его частично вдохновила «Игра по разработке нового продукта», статья HBR 1986 года, соавтором которой стал другой из нас (Хиротака Такеучи).Поскольку scrum и его производные используются как минимум в пять раз чаще, чем другие методы, мы будем использовать его методологии для иллюстрации гибких практик.

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

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

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

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

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

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

2. Понять, где Agile работает, а где нет

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

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

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

По этому пути пошла компания

OpenView Venture Partners, которая инвестировала около 30 компаний.Узнав об Agile от некоторых компаний, входящих в его портфель, Скотт Максвелл, основатель фирмы, начал использовать ее методологии в самой фирме. Он обнаружил, что они легче подходят для одних занятий, чем для других. Например, Agile хорошо зарекомендовал себя для стратегического планирования и маркетинга, где сложные проблемы часто можно разбить на модули и решить творческими мультидисциплинарными командами. В случае продажи этого не произошло: любой торговый звонок может изменить список дел представителя на месте, и было бы слишком сложно и долго собирать команду продаж, изменять портфель заказов и переназначать учетные записи каждый час. .

Гибкие инновации зависят от количества активных участников.

Maxwell предоставил компаниям, входящим в портфель OpenView, обучение принципам и методам гибкой разработки и позволило им решить, следует ли применять этот подход. Некоторым из них сразу понравилась идея реализовать ее; у других были другие приоритеты, и они решили воздержаться. Интронис был одним из его поклонников. В то время ее маркетинговое подразделение полагалось на годовой план, ориентированный в первую очередь на выставки. Его отдел продаж жаловался, что маркетинг был слишком консервативным и не приносил результатов.Поэтому компания наняла Ричарда Делахайе, веб-разработчика, ставшего маркетологом, для внедрения гибкой разработки. Под его руководством команда маркетинга научилась, например, тому, как проводить тематический вебинар за несколько дней, а не за несколько недель. (Быстро подготовленная сессия по вредоносному ПО CryptoLocker привлекла 600 регистрантов — все еще рекорд компании.) Сегодня члены команды продолжают создавать календари и бюджеты для подразделения цифрового маркетинга, но с гораздо меньшим количеством деталей по позициям и большей гибкостью для случайных разработок.Команда продаж намного счастливее.

3. Начните с малого и пусть слово распространится

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

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

В 2012 году Том работал менеджером в отделе корпоративного маркетинга группы исследований и разработок, ответственной за открытие технологий, которые могут революционизировать предложения Deere. Джейсон Брантли, глава подразделения, был обеспокоен тем, что традиционные методы управления проектами замедляют внедрение инноваций, и эти двое решили посмотреть, сможет ли Agile ускорить процесс. Томе пригласил двух других руководителей подразделений на учебные курсы по гибкой методологии. Но вся терминология и примеры взяты из программного обеспечения, и для одного из менеджеров, не имевшего опыта работы с программным обеспечением, они показались тарабарщиной.Томе понял, что другие отреагируют таким же образом, поэтому он разыскал гибкого коуча, который знал, как работать с людьми, не имеющими опыта работы с программным обеспечением. За последние несколько лет он и тренер тренировали команды во всех пяти центрах группы НИОКР. Томе также начал публиковать еженедельные одностраничные статьи о принципах и практиках гибкой разработки, которые рассылались всем желающим по электронной почте, а затем размещались на сайте Deere Yammer. Сотни сотрудников Deere присоединились к дискуссионной группе. «Я хотел разработать базу знаний об Agile, специфичную для Deere, чтобы любой сотрудник организации мог ее понять», — говорит Томе.«Это заложило бы основу для перехода к Agile в любую часть компании».

Используя гибкие методы, Enterprise Advanced Marketing значительно сократил время цикла инновационных проектов — в некоторых случаях более чем на 75%. Одним из примеров является разработка примерно за восемь месяцев рабочего прототипа новой «формы машины», которую компания Deere еще не раскрыла. «Если бы все прошло безупречно в рамках традиционного процесса, — говорит Брантли, — это в лучшем случае длилось бы полтора года, а может и два с половиной или три года.«Agile также привел к другим улучшениям. Вовлеченность команды и счастье в подразделении быстро перешли из нижней трети результатов компании в верхнюю треть. Качество улучшилось. Скорость (измеряемая количеством работы, выполненной в каждом спринте) увеличивалась в среднем более чем на 200%; некоторые команды достигли роста более чем на 400%, а одна команда взлетела на 800%.

Такой успех привлекает внимание. Сегодня, по словам Томе, почти в каждой области в John Deere кто-то либо начинает использовать Agile, либо думает о том, как его можно использовать.

4. Разрешить «мастерским» командам настраивать свои методы работы

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

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

Дополнительная литература

• Бережливая работа с знаниями

  Управление людьми
  Особенность

  • Брэдли Статс и Дэвид М.Аптон

  Принципы Toyota могут применяться в операциях, требующих экспертизы.

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

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

Spotify, компания, занимающаяся потоковой передачей музыки, является примером опытного адаптера. Основанная в 2006 году, компания была гибкой с момента рождения, и вся ее бизнес-модель, от разработки продукта до маркетинга и общего управления, ориентирована на улучшение качества обслуживания клиентов за счет гибких инноваций. Но высшие руководители больше не диктуют конкретные практики; напротив, они поощряют экспериментирование и гибкость, если изменения согласуются с принципами гибкой разработки и могут улучшить результаты.В результате практика различается в 70 «отрядах» компании (название Spotify для гибких инновационных команд) и ее «отделениях» (термин компании для обозначения функциональных компетенций, таких как разработка пользовательского интерфейса и тестирование качества). Хотя почти каждый отряд состоит из небольшой кросс-функциональной команды и использует ту или иную форму визуального отслеживания прогресса, ранжирования приоритетов, адаптивного планирования и мозговых штурмов о том, как улучшить рабочий процесс, многие команды пропускают диаграммы «выгорания» (которые показывают работу выполненная и оставшаяся работа), которые являются общей чертой гибких команд.Они также не всегда измеряют скорость, ведут отчеты о проделанной работе и не используют одни и те же методы для оценки времени, необходимого для выполнения данной задачи. Эти отряды протестировали свои модификации и обнаружили, что они улучшают результаты.

5. Практикуйте Agile на вершине

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

Ряд компаний перераспределили 25% или более рабочего времени избранных руководителей из функциональной разрозненности в группы гибких руководителей. Эти группы упорядочивают портфели заказов в масштабе предприятия, создают и координируют гибкие команды в других частях организации для решения высших приоритетов и систематически устраняют препятствия на пути к их успеху. Вот три примера C-Suite, которые взяли на себя Agile:

1.Догоняют войска.

Systematic, компания-разработчик программного обеспечения с 525 сотрудниками, начала применять гибкие методологии в 2005 году. Когда они распространились на все ее команды разработки программного обеспечения, Майкл Холм, генеральный директор и соучредитель компании, начал беспокоиться о том, что его руководящая команда препятствует прогрессу. «У меня было такое чувство, что я говорил:« Следуй за мной — я за тобой », — сказал он нам. «Команды разработчиков использовали scrum и делали вещи по-другому, в то время как команда менеджеров застряла в том же старомодном стиле» — двигалась слишком медленно и полагалась на слишком много письменных отчетов, которые всегда казались устаревшими.Поэтому в 2010 году Холм решил руководить своей исполнительной группой из девяти человек как гибкой командой.

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

2. Ускорение корпоративного перехода.

В 2015 году General Electric провела ребрендинг в «цифровую промышленную компанию» с акцентом на продукты с цифровой поддержкой. Частью преобразования было создание GE Digital, организационного подразделения, в которое входят все более чем 20 000 сотрудников компании, связанных с программным обеспечением.Брэд Сурак, который начал свою карьеру в качестве инженера-программиста, а сейчас является главным операционным директором GE Digital, хорошо знал Agile. Он пилотировал схватку с командой руководителей, ответственных за разработку промышленных интернет-приложений, а затем, совсем недавно, начал применять ее к процессам управления нового подразделения, таким как операционные обзоры. Сурак является инициативным владельцем, а технический руководитель — мастером схватки. Вместе они определили приоритетные задачи, которые должна решить исполнительная группа, включая упрощение административного процесса, которому команды следуют при приобретении оборудования, и решение сложных вопросов ценообразования для продуктов, требующих участия нескольких предприятий GE.

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

3. Объединение отделов и функций по единому видению.

Эрик Мартелла, вице-президент и генеральный менеджер винодельни Mission Bell, производственного предприятия Constellation Brands, представил Agile и помог ему распространиться по всей организации. Руководители каждого отдела выступали в качестве владельцев инициативы в различных гибких командах своих отделов.Эти отдельные команды достигли впечатляющих результатов, но Мартелла беспокоился, что их время тратится слишком мало, а приоритеты отдела и предприятия не всегда совпадают. Он решил объединить руководителей отделов в гибкую команду руководителей, сосредоточенную на корпоративных инициативах, которые имеют наибольшую ценность и дают наибольшие возможности для межфункционального сотрудничества, например, увеличение потоков процессов на складе.

Команда отвечает за создание и постоянное уточнение отставания по приоритетам предприятия, гарантируя, что гибкие команды работают над правильными проблемами и имеют достаточные ресурсы.Члены команды также защищают организацию от любимых проектов, которые не заслуживают высокого приоритета. Например, вскоре после того, как Мартелла начал внедрять Agile, он получил электронное письмо от начальника корпоративного офиса Constellation, в котором предлагалось, чтобы винодельня изучило личное увлечение отправителя. Раньше Мартелла мог ответить: «Хорошо, мы прыгнем прямо на это». Вместо этого он ответил, что винодельня следует принципам Agile: идея будет добавлена ​​в список потенциальных возможностей и будет расставлена ​​по приоритетам.Так получилось, что руководителю понравился такой подход — и когда ему сообщили, что его предложению присвоен низкий приоритет, он с готовностью принял это решение.

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

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

6. Разрушьте барьеры на пути к гибкому поведению

Исследование, проведенное Scrum Alliance, независимой некоммерческой организацией, насчитывающей более 400 000 участников, показало, что более 70% практиков Agile сообщают о напряженности между своими командами и остальной частью организации. Неудивительно: они следуют разным дорожным картам и движутся с разной скоростью.

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

Дополнительная литература

• Расшифровка ДНК производственной системы Toyota

  Управление человеческими ресурсами
  Статья в журнале

  • Стивен Спир
  • Х. Кент Боуэн

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

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

Получите все на одной странице.

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

Не меняйте структуру сразу; вместо этого поменяйте роли.

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

Назовите только одного босса для каждого решения.

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

Сосредоточьтесь на командах, а не на отдельных лицах.

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

Руководите вопросами, а не приказами.

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