Что такое agile революция
Перейти к содержимому

Что такое agile революция

  • автор:

Что такое Agile

Александр Машков

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

Что такое Agile

Слушай аудиоверсию этой статьи в нашем подкасте:

Agile (от англ. «гибкий») — это методика гибкого подхода к управлению проектами разработки программного обеспечения. Иногда встречается Agile software development — гибкая разработка ПО. Этот метод вырос в небольших командах разработчиков, и по сей день применяется в небольших коллективах. Ценности, принципы и инструменты Agile тем не менее вышли далеко за рамки разработки.

Не хочется читать? Тогда можешь посмотреть про Agile наш ролик на YouTube

История Agile

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

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

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

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

В 90-е годы ХХ века внутри среды разработчиков возникла целая серия «лёгких методологий» — сочетание формализованного и неформального подхода. А в 2001 году лидеры движения решили собраться вместе и обсудить — а не пора ли свести воедино наши принципы и результаты. 17 разработчиков, практикующих методики гибкого управления, собрались вместе на горном курорте Юты и составили Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development или просто Agile Manifesto). Здесь и возникает понятие «agile».

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

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

Agile

В чём суть Agile

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

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

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

Как работает Agile

4 ценности и 12 принципов Agile-методологии

Давай разберём, что входит в Agile? В статье про методы управления проектами я дал такое определение:

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

Так вот Аgile методология — это ценности, описанные в Agile Manifesto или принципы Agile:

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

Работа Agile

В Манифесте описаны ещё и принципы — их 12. Они даны скорее в попытке разжевать ценности. Так что пробежимся по ним кратко:

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

Ну вот, те же ценности, только поставленные на почву практики.

Подходы, методы и инструменты Agile

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

Scrum

SCRUM

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

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

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

Канбан-доска

Второй инструмент — Канбан-метод. Этот инструмент невероятно популярный, потому что очень гибкий. Более гибкий, чем Scrum.

Суть в том, чтобы использовать Канбан-доску — можешь воспользоваться нашим сервисом WEEEK — и работать с ней по шести принципам:

  1. 1. Визуализируй задачи в столбцах доски. Появилась новая задача — сразу на доску!
  2. 2. Ограничь количество задач — в каждом столбце определённое количество задач
  3. 3. Управляй потоком работы — смотри, как задачи движутся по доске. Помни, определённое количество для каждого столбца, нигде не должно копиться пробок из задач, всё движется и меняется
  4. 4. Используй понятные для всех правила добавления и движения задач
  5. 5. Делайте встречи с обратной связью — чтобы контролировать работу в реальном мире
  6. 6. Улучшай процессы везде, где только можно

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

XP — экстремальное программирование

Экстремальное программирование (от англ. XP, eXtreme Programming) — ещё одна гибкая методология разработки ПО. Экстремальное программирование отлично подходит для комплексных продуктов и неопределённых процессов.

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

В основе XP 4 главных составляющих:

  • кодирование,
  • тестирование,
  • дизайн,
  • слушание (то есть получение обратной связи от юзеров).

Тут в основе ценности простоты, коммуникации, простоты, уважения — и доля смелости.

Lean

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

Тут всё крутится вокруг термина MVP — minimum viable product, минимально жизнеспособный продукт.

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

Lean гласит — покажи на рынке продукт, пойми, нужен ли он, а потом улучшай в зависимости от реальных требований рынка. Про механизм работы Lean подробно и интересно пишет Эрик Рис в книге Бизнес с нуля: Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

Плюсы и минусы Agile

Плюсы

  • Адаптивность к переменам
  • Высокая вовлечённость команды

Как объяснить руководству, что такое Agile

Метафоры могут помочь осветить ключевые принципы Agile. Вот несколько советов от Forbes.com.

1. Цель фирмы: коперниковская революция

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

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

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

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

2. Архитектура работы: американский футбол против баскетбола

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

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

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

Это, в свою очередь, приводит к очень значительной разнице в реальном игровом времени. В баскетболе на двухчасовую игру отводится не менее 60 минут игрового времени. Напротив, 3-часовая игра в американский футбол НФЛ имеет только 11 минут фактического игрового времени.

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

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

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

3. Динамика фирмы: PC против приложений iPhone

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

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

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

Об Agile: революция или опыт старших?

Сегодня у меня в блоге — гостевой пост. На этот раз — от Николая Заостровцева. Идея поста возникла в обсуждении на fb моей прошлой заметки “Об Agile методологиях” (https://medium.com/@allo/%D0%BE%D0%B1-agile-%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%D1%85-5427711ce97c). Кстати, если хотите написать гостевой пост по тематике моего блога — пишите, буду рад. Далее текст Николая.

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

Действительно ли Agile — новый революционный подход? Говоря про Agile чаще всего начинают с манифеста и принципов, а дальше вспоминают Scrum или Канбан.

Давайте посмотрим с другой стороны.

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

Производство автомобилей

Начиналось все с одиночек, конструкторов-энтузиастов. Кустарно-ремесленное производство для себя или “на заказ”.

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

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

Все ли мы хотим одинаковый автомобиль? Вряд ли. Чем больше разнообразия, тем менее эффективен для этой задачи становится выталкивающий конвейер. Дешево произведенные, но не востребованные изделия переполняют склад. Заполненные буферные зоны между цехами мешают работе следующих цехов, требуется синхронизация работ. Когда требуется выпускать разнообразную продукцию, более эффективным становится “вытягивающий конвейер”. Работу можно передать следующему, только если он готов её принять. Получается, что инициатором является последний участок в цепи, который сообщает о том, что он свободен и готов принять работу от предыдущего, “вытягивая” её на себя. Дополнительно, ограничивается количество изделий над которыми идет работа (“незавершенное производство”). Вытягивание, ограничение задач в работе, визуализация — основные правила Канбан-подхода, JIT, производственной системы Тойота и других.

Недостаточно сделать какой-то продукт. Мы хотим качественный. Когда выпускается партия конфет, то можно поставить в конце конвейера пост проверки качества, который откроет коробку, проверит количество конфет и качество укладки, положит в коробку бумажку “Проверено ОТК, пост 9, дата время”. С автомобилем сложнее. Выкатить готовый автомобиль в зону контроля, разобрать там до мельчайших деталей, убедиться, что все ОК и собрать потом обратно без потери качества — не выйдет. Качество при производстве сложных изделий можно добиться только одним способом — делая акцент на процесс. Необходимо создавать и постоянно совершенствовать процесс производства, добиваясь качества на каждом шаге. Стандартом де-факто для систем менеджмента качества стал цикл Деминга PDCA — планируй-делай-проверяй-воздействуй. Метод показал свою эффективность в процессе восстановления производства послевоенной Японии, за что в 1951 году в Японии была учреждена премия Деминга. Примерно в тоже время в Японии стал применяться Кайдзен — подход непрерывного совершенствования, одной из составных частей которого используется чередование циклов PDCA/SDCA (добавляется этап стандартизации, с последующей работой по стандарту и его корректировкой). Одно из правил Кайдзен — акцент на процесс, не на результат. Качественный результат — следствие качественного процесса.

Выше были примеры, как производится изделие, которое уже придумано и спроектировано. А как создается новое? Представим, что мы хотим заказать новый уникальный автомобиль. Не выбрать опции к готовому, а создать новый, уникальный. Разве сложно? Автомобиль — стандартная конструкция. Мотор и четыре колеса. Ничего принципиально нового пока не изобрели. Человек занимается выпуском автомобилей 250 лет, должен был научиться. Есть куча готовых запчастей, наработок.

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

  • Заказчик озвучивает свои требования
  • Менеджер дает сроки и стоимость, заключает договор
  • Аналитик составляет техническое задание
  • Дизайнер рисует концепт автомобиля
  • Конструктор по концепту и техническому заданию делает чертежи всех деталей
  • Производство по чертежам быстро производит новый уникальный автомобиль
  • Автомобиль проходит приемочное тестирование
  • На выходе нас ждет счастливый заказчик.

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

  • Автомобиль сконструирован с соблюдением срока и бюджета
  • Автомобиль на 100% удовлетворит все требования заказчика.
  • Автомобиль будет отличного качества, безотказно работать десятилетиями

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

Как создавать новое

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

Примерно к таким выводам и пришли Hirotaka Takeuchi и Ikujiro Nonaka, проведя исследование, как производственные компании создают новые продукты. Итогом стала статья “The New New Product Development Game”, опубликованная в Harvard Business Review в 1986 году. В ней появился термин Scrum. Jeff Sutherland и Ken Schwaber, изучив статью и производственные подходы, лежащие в её основе, создали через несколько лет первую версию самого популярного сейчас Agile-фреймворка Scrum.

Scrum

Основное предназначение Scrum — создавать уникальные сложные продукты, инновации, работать в режиме неопределенности.

Суть Scrum — маленькая команда профессионалов. В команде есть все, кто необходим для решения задачи. Нет должностей, жесткого распределения обязанностей. Главное — общий результат — созданный продукт. Коллективный разум команды выше разума одного руководителя. Происходит “инверсия контроля”. Задачей руководителя становится не управлять людьми, а “помогать и не мешать”. Создавать им условия для работы и устранять препятствия.

Как при этом избежать хаоса и добиться лучшего результата?

Во-первых, использовать лучшие практики. Основные события и артефакты Scrum — частный случай использования производственного цикла PDCA/SDCA для непрерывного совершенствования.

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

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

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

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

С программистами — примерно также. Кодер, работающий по четкой задаче, винтик с конвейера — не будет эффективен в Agile команде. Нужны люди с более широкими навыками, ответственностью, T-shaped people. Звезда-одиночка или фрилансер тоже не подойдут, нужен командный игрок.

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

Применимость Agile

  • Можно ли использовать Agile в моей сфере — ИТ или вне ИТ?
  • А зачем?

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

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

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

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

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

Если идет поток разнообразных изделий или задач — выталкивающий конвейер будет приводить к потерям. Будут постоянно возникать ситуации — “мои пули вылетели”. Административный ресурс будет занят разрешением конфликтов и проблем. Вместо этого более эффективно использовать Канбан, чтобы синхронизировать работу. Не важно, что за поток — обработка заявок в ИТ, небольшие заказы, обработка клиентов в CRM, служба поддержки клиентов или заключение разных договоров. Или даже если просто хотите упорядочить свою жизнь, свой поток дел, когда задачи прилетают со всех сторон — личные, семейные, рабочие, окружение и так далее.

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

Но ведь Scrum — работа маленькой команды! Что делать, если её недостаточно? Для больших компаний есть различные варианты масштабирования Scrum, которые позволяют объединять работу десятков и сотен креативных команд. Варианты есть, только часто не обращают внимание на ключевое слово — масштабирования. Масштабирование — когда Вы добились успеха с одной или несколькими командами, работающими независимо над небольшими продуктами. А после этого уже смогли организовать совместную работу нескольких таких команд.

Завершая мысль

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

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

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

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

Постараюсь в следующих постах разобрать идеи и принципы Scrum более подробно.

Agile: революция или… эволюция?

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

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

Появление Agile

В 2001 году группа разработчиков программного обеспечения (ПО) собралась в г. Юта (США), чтобы предложить новую методологию управления проектами по разработке ПО в противовес классическим «бюрократическим и тяжеловесным» подходам. Прийти к консенсусу по методологии не удалось, зато появился «Agile-манифест», который позиционировался как радикально новый подход к управлению проектами. С легкой руки Кена Швабера (Ken Schwaber) Agile начинают называть революцией в управлении проектами.
Идеи, которые легли в основу Agile-манифеста, появились задолго до 2001 года.

Обратимся к истории (см. рис. 1).

Рис. 1. PM/BPM Timeline

Фредерик встретил Генри

Корни Agile уходят в 1878 год, когда Фредерик Тейлор (Frederick Taylor) представил теорию «Научного менеджмента». Тейлора ассоциируют со стандартизацией труда на производстве и повышением производительности бизнес-процессов. Однако его вклад в развитие инструментов управления проектами и процессами этим не ограничивается. Дело в том, что в 1887г. Фредерик Тейлор нанял помощником Генри Гантта (Henry Gantt), который в начале 20 века предложил знакомый многим способ визуализации план-графика проекта (см. рис.2). Спустя 100 лет диаграмма Гантта все еще остается популярным инструментом среди руководителей проектов.

Рис.2 Диаграмма Гантта

Рождение Lean и итеративных практик

Труды Тейлора дали толчок дальнейшему изучению бизнес-процессов. Фрэнк и Лилиан Гилбрет (Frank and Lilian Gilbreth) в 1921г. предложили использовать диаграммы процесса (process charts) для его визуализации, анализа и усовершенствования. В основе их рекомендаций по оптимизации лежали: стандартизация процесса, устранение потерь (waste) и упрощение работы сотрудников.

В 1930г. Лилиан Гилбрет презентовала способ визуализации потока работ с помощью инструмента, известного сегодня как Kanban-доска: «We had three rows of hooks, one marked “Jobs to be done”, one marked “Jobs being done” and a third marked ”Jobs completed” with tags which were moved from hook to hook to indicate the progress of the task. (Источник: 1930 Speech by Lillian Gilbreth to National Federation of Business and Professional Women’s Clubs in New York)».

Рис.4 Two-week sprint

Киичиро Тойода (Kiichiro Toyoda) познакомился с работами Гилбретов в 1929 году во время поездки в США и Европу. В 50-х годах компания Тойота стала пионером в адаптации идей Гилбретов и Деминга. Производственная система Тойота (Toyota Production System) вобрала в себя идеи стандартизации работы, устранения потерь, непрерывного совершенствования по итеративному принципу, канбан и проч.

На волне роста интереса к японским автопроизводителям в 80-х годах в США появился термин Lean Production (бережливое производство). Lean — маркетинговое название принципов производственной системы Тойота. Подход быстро набрал популярность, и вскоре появились адаптации Lean для других отраслей. Концепция Lean software development стала одной из первых agile-методологий по разработке программного обеспечения.

В это же время в Японии развивались фабрики разработки ПО (Software factories). По мере ослабления барьеров в торговле и глобализации бизнеса приходилось адаптировать практики параллельной разработки для географически распределенных команд. Идеи устранения потерь (elimination of waste), стандартизации ролей и упрощения процесса добрались до самой прогрессивной на сегодняшний день отрасли спустя 60 лет после возникновения.

«Железный» треугольник, инкрементальные и итеративные практики

Давайте вернемся к «классическому» управлению проектами и вспомним диаграммы процессов Гилбретов. Именно их компания DuPont адаптировала и положила в основу своего Critical Path Method (CPM). Диаграмма Гантта, критический путь и «железный» треугольник стали популярными инструментами руководителей проектов в 60-х годов прошлого века. Спустя 40 лет идею треугольника стали использовать последователи agile для пояснения отличий классического управления проектами и agile-практик (см. рис. 5).

Рис. 5. Agile-подход

В 60-х годах прозвучали первые упоминания об инкрементальных и итеративных практиках управления проектами. Впервые это произошло в проекте Меркурий, который реализовала NASA в 1958-1963 гг. Чуть позже, с 1968 года, началась адаптация итеративных практик под проекты разработки ПО.
Через некоторое время итеративные практики включили в фреймворк PROMPT (прообраз современного PRINCE2) и руководство PMBOK (упоминается как спиральный жизненный цикл проекта, spiral project lifecycle).

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

При подготовке статьи использовались материалы: McKenna T, Whitty SJ. (2013) Agile is Not the End-Game of Project Management Methodologies. In: Proceedings of the Annual Project Management Australia Conference Incorporating the PMI Australia National Conference (PMOz), Melbourne, 17‐18 September 2013.

Добавить комментарий

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