Алексей Корсун

Управление проектами по разработке ПО

Agile-блог   

Главная » 2017 » Март » 22 » Когда применим Agile? И как это — работать по Agile?
19:42
Когда применим Agile? И как это — работать по Agile?

Один из самых популярных вопросов у интересующихся: «Когда этот ваш Agile применять можно, а когда нет?»

Можно ли применять Agile в управлении бухгалтерским отделом? В юридической компании? Работает ли Agile в банках или в строительстве?

Agile это множество различных методик, объединённых одними и теми же принципами, описанными в манифесте.

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

Принцип: изменение требований — это нормально и приветствуется

  • Важно ли это в разработке программного обеспечения?

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

  • Важно ли это в проектировании зданий?

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

  • Важно ли это в бухгалтерии?

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

  • А в финансовом консультировании?

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

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

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

  • В проектировании зданий — полезно?

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

  • В разработке программного обеспечения?

Тоже да.

  • В бухгалтерии?

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

Что уже можно сказать о применимости Agile?

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

Внедрение Agile оправдано, если соблюдаются следующие условия:

  • сфера работ — интеллектуальная, не молотком стучим, а в основном думаем
  • работа проектная, а не процессная, то есть делаем не однообразные повторяющиеся действия на конвеере (или по составлению отчётов), а каждый раз хоть в чём-то — но уникальное творение.
  • работа командная — то есть не 1 человек делает проект самостоятельно

Но, позвольте, я слышал, что на конвеерах Toyota тоже Agile используют!

Здесь подходим к хорошему вопросу терминологии.

Agile — пошёл от IT. Но в то же время на заводах Toyota задолго до Agile использовали другой подход. Не вдаваясь в исторический экскурс о TPS и Lean и их родителе, обобщённо называем его Lean — бережливое производство. Оно же «бережливая разработка» или «бережливое проектирование» итп.

В свою очередь принципы Lean:

  1. Целостное видение всей системы создания ценности
  2. Акцент на уменьшение времени поставки заказчику
  3. Исключение потерь
  4. Предельно отсроченное принятие решений (иначе «принятие решений на основе фактов, а не предположений»)
  5. Акцент на обучении
  6. Мотивация команды
  7. Постоянное интегрирование (имеется в виду, что постоянно нужно иметь результат труда, который можно испытать, а не какие-то обрывки результата в разобранном виде)

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

Когда можно применять Lean?

  • проектная и процессная (в особенности) работа
  • практически любая сфера работ (мне не приходят в голову сейчас какие-то ограничения)

И что, Lean лучше Agile?

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

Из зарубежного источника очень правильная картинка:

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

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

Применимость или не применимость Agile и Lean в компании зависит не от слов "внедряем Agile" или "внедряем Lean", а от конкретного перечня практик Agile или Lean, которые внедряются в данной компании.

Чем отличается работа по Agile или Lean от «просто работы»?

И та и другая группа методик содержит определённые установки, цель которых трансформировать культуру компании.
Например, в одна из таких установок в Lean: «ожидания — это ВСЕГДА зло». ВСЕГДА.

Любыми способами устраняем ожидания. Отправили документ на «согласование» и взялись за другую работу, и «ждёте» его согласования несколько дней? Плохо! По Lean так не делают. Надо заняться согласованием лично — ускорить его. Не должно быть потерянного времени на ожиданиях и заниматься в это время другой работой — это не «эффективность», а прятание проблемы с долгим согласованиями под ковёр.

В Agile одна из установок «поговорив о задаче, можно сэкономить кучу времени на её решении».

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

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

А установки сопровождаются конкретными процессами

Как вы увидели Agile и Lean это просто набор принципов. А вот конкретное их применение называется процеcсом управления (или разработки). По принципам Agile или по принципам Lean построены десятки разных систем: Scrum, Kanban, TPS, XP, Scrumban и прочим. То есть:

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


И ещё раз про применимость Agile (и Lean)

Разные процессы этих семейств более или менее подходят к разным ситуациям. Карта примерно такая:

То есть прежде, чем говорить, подойдёт или нет Agile вашей компании нужно понимать, что Agile и Lean огромны — и какая-то часть ТОЧНО очень хорошо ляжет на процессы вашей компании и поможет вам сделать их лучше. Но не стоит хвататься за первый услышанный процесс. Подумайте какой подойдёт лучше. Или спросите меня ;)

Просмотров: 610 | Добавил: akorsun | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Алексей Корсун
Консультант по управлению проектами и постановке процессов

me@akorsun.ru
skype: akorsun
Архив записей
Поиск
Отзывы
JetBrains, Вадим Гуров

За несколько лекций Алексей донес до нашей команды основные принципы Scrum'a, развеял наши стереотипы и заблуждения, придал начальный положительный импульс. Первые два спринта мы, конечно, слили, но благодаря тому, что Алексей курировал основные мероприятия в каждом спринте, мы быстро набрали форму, и вполне успешно завершили последующие спринты. » читать далее
Avia Sales, Борис Каплуновский

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