Agile методология: принципы и правила применения

226
Фото © shutterstock.com
Фото © shutterstock.com
Система работы завода «Тойота» уже стала классической и успешной менеджмент-моделью. У каждого работника предприятия была возможность в любое время остановить конвейер в целях устранения дефекта, неполадки или внесения своего рационализаторского предложения. Именно на таком подходе основана философия Agile. Изначально Agile методология около 10-15 лет назад была методом разработки программного обеспечения в малочисленных командах. В данный момент Agile методология – это новая культура управления крупными предприятиями. Сегодня любой прогрессивный менеджер знает, что представляет собой Agile.

Продукты и сервисы создаются, как правило, по единой классической схеме. Особенно это относится к IT-индустрии. Такую схему называют каскадной, или итеративной методологией разработки, а в английском языке – waterfall development («водопад»). По какой причине схема носит такое название? Все дело в том, что, если вы уже утвердили план программного продукта, то не можете приостановить его или внести коррективы до реализации. Совершенно иной принцип имеет Agile методология. Waterfall – понятие, которое к ней неприменимо. Это качественно новый подход к созданию продукции. Основу методологии составляет простая мысль – у каждого участника есть возможность внесения полезных предложений по оптимизации процесса, остановки конвейера с целью переосмыслить задачи и общее дело.

Agile методология имеет основу, наделенную рядом характеристик. Среди них:

  • Быстрая реакция на изменения.
  • Самостоятельная организация процесса производства.
  • Предсказуемость.
  • Наличие непрерывной и постоянной обратной связи.
  • Разграничение рисков.

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

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

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

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

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

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

Существует Agile-манифест, где сказано об основных принципах методологии:

  1. Самое главное – регулярно и заблаговременно поставлять ценный продукт, удовлетворяя тем самым потребности заказчика. В соответствии с данным принципом Agile методологии создатели продукта обязаны не только реализовать требования, обозначенные в проектных документах, но и как можно раньше давать потребителю знать, что это будет за товар, с какими особенностями и характеристиками. Если продукция не удовлетворяет заказчика, необходимо срочно корректировать ее с учетом замечаний. Поскольку, выводя в рыночную среду новый продукт, есть большой риск ошибиться, логично использовать технические требования к созданию минимально жизнеспособного продукта minimum viable product (MVP), основная задача которого – проверить, насколько ключевые качества востребованы среди покупателей, и оценить уровень спроса.
  2. Требования изменить можно, и это будет воспринято положительно, если речь идет о повышении конкурентных качеств товара. Обычно их меняют по окончании завершающего этапа разработки. Данный принцип Agile методологии на сегодняшний день очень важен, ведь продукция высокотехнологичных сфер в кратчайшие сроки становится устаревшей и уступает место новой. Сформировать ряд требований к продукту можно уже в финале его создания. Обычно это бывает вызвано изменениями на рынке или в среде конкурентов. Отметим, реализация данного принципа невозможна, если мы говорим о каскадной управленческой модели, или же она реальна, но обойдется спонсору в круглую сумму. Но чем больше будет происходить слияние технологий, тем более актуальной станет подготовка очередной версии продукта для опережения конкурентов.
  3. Команда и заказчик должны непрерывно взаимодействовать на всех этапах создания товара. Данное правило носит примерно тот же характер, что и пожелания клиента. Это самое главное. Если нет постоянного взаимодействия, достичь поставленных целей сложно.
  4. Agile методология гласит, что реализацией проектов должны заниматься исключительно мотивированные профессионалы. Позаботьтесь о создании должных условий и доверьтесь специалистам. В этом случае вероятность качественной реализации проекта очень высока. Современная наука говорит о том, что интеллектуальную работу сложно стимулировать финансовыми поощрениями. А потому сотрудничать следует только с теми специалистами, для которых главной мотивацией является непосредственно проект. Все, что им нужно, – это получить возможность работать в приемлемых условиях и заручиться доверием заказчика.
  5. Лучший способ коммуникации – личный контакт. Желательно, чтобы все задействованные в проекте лица располагались на совместной территории. Пусть это будет одно здание. В идеале там же должен находиться и сам заказчик.
  6. Проект прогрессирует, если продукт работает. Заказчика интересует готовый товар с теми или иными характеристиками. Еще один успешно выполненный этап процесса ему ни о чем не говорит. Заказчик должен видеть, что продукт развивается, а главное, работает и отвечает заявленным требованиям. Если его форма и наполнение приближаются к желаемой модели, значит, разработчики действуют эффективно.
  7. Спонсорам, заказчику и разработчикам необходимо заботиться об обеспечении постоянного темпа деятельности. Если все участники процесса оперируют в устойчивом ритме, то перестают волноваться из-за вероятности аврала или срыва сроков.
  8. Следует обращать внимание и на техническое совершенство и качество проектирования. Agile методология гласит, что разработка проекта должна быть гибкой, без ущерба качеству продукта и упрощения его характеристик. Отметим, к этому нередко прибегают, чтобы ускорить процесс создания проекта и оптимизировать его.
  9. Не стоит забывать о принципе простоты. Применяя его, вы сводите вероятность выполнять лишние действия к минимуму. Суть не в том, чтобы упрощать характеристики продукта, а в том, чтобы избавляться от ненужных операций и не включать в проект нечто ненужное для его использования по назначению.
  10. Самоорганизующиеся команды всегда генерируют лучшие идеи архитектурного, технического и иного плана. В этом уверены авторы Agile-манифеста. А потому все участники команды должны разрабатывать требования и принимать решения сообща. Если у членов коллектива общие интересы и единые цели, самоорганизация становится более эффективной.
  11. Внешние условия постоянно меняются. В связи с этим следует постоянно анализировать и адаптироваться к обстановке, искать методы улучшения эффективности деятельности. Agile методология ориентирована именно на гибкость разработчиков. Это то, к чему нужно стремиться.

Мнение эксперта

Перспективы Agile методологии в России

Андрей Кочешков,
главный аналитик ОАО «Издательство «Просвещение»

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

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

Гибкие методологии: Agile, Lean, Scrum и другие

В Agile Manifesto определены особые принципы. На их основе сформирована гибкая методология разработки Agile.

  • Agile Modeling (AM). Здесь применяются процедуры по моделированию (в том числе проверка кодом модели) и документированию в ходе создания ПО. Меньше внимания уделяется процедурам по проектированию и строительству диаграмм на UМL. Не сказано о таких областях, как разработка, тестирование, управление проектом, развертывание и сопровождение.
  • Agile Unified Process (AUP) является унифицированной версией методологии RUP (IBM Rational Unified Process), которую сформировал Скотт Амблер. АUP определяет модель разработки ПО в рамках приложений для бизнеса.
  • Agile Data Method (ADM) — это итеративные методики гибкого создания ПО в комплексе, которые делают акцент на разработку решений и требований. Разные кросс-функциональные команды сотрудничают между собой.
  • Dynamic Systems Development Method (DSDM) – инкрементный и итеративный метод, основа которого – быстрая разработка приложений (Rapid Application Development – RAD). Акцент делают на то, чтобы максимально привлечь конечного потребителя к созданию продукции.
  • Essential Unified Process (EssUP). Автор подхода – Ивар Якобсон. Подход наделен методами итеративного создания ПО. Акцент делается на архитектуру продукции и наработанные практики команды, заимствованные из RUP, CMMI и Agile Development. Суть идеи состоит в использовании лишь тех методов и техник, которые применяются в конкретном случае. Именно их выбор является основой определения целевого процесса. Данный подход отличается от RUP с взаимосвязанными методами и практиками. Здесь же есть гибкость и возможность вычленения необходимых элементов из всего, что доступно.
  • Extreme Programming (XP), или экстремальное программирование. Суть метода – в использовании уже имеющихся лучших техник в сфере создания ПО и усовершенствовании их. Данный подход и обычная практика отличаются друг от друга, в частности тем, что в последнем случае программист проводит последовательную проверку написанного своим коллегой кода. Экстремальное программирование предполагает параллельную проверку, что способствует более быстрому выпуску продукции, но вместе с тем увеличивает и риски.
  • Feature-Driven Development (FDD). В рамках использования метода есть главный запрет, заключающийся в том, что реализация каждой функции должна осуществляться в течение двух недель и не более. В идеале ее разработка производится за один раз. Если это невозможно, функцию разбивают на несколько и реализовывают плавно.
  • Getting Real (GR) — при использовании метода не прибегают к процедурам функциональных спецификаций, используемых для web-приложений. Разработку начинают с обратной стороны, то есть сначала задумываются о дизайне и интерфейсе, а потом – о функциональном наполнении.
  • OpenUP (OUP) — в основу разработки подхода положен RUР. Метод определяет итеративно-инкрементальный способ создания ПО. В рамках подхода сказано о жизненном цикле разработки (фазах запуска, уточнения, разработки и передачи заказчику). Метод реализуют в несколько этапов, проверяя определенные контрольные точки, что способствует повышению эффективности контроля и мониторинга воплощения проекта в жизнь. Все решения, касающиеся проекта, принимаются вовремя.
  • Lean Software Development. Основа подхода – концепция бережливого управления производственной компанией (lean production, lean manufacturing).
  • Scrum является одним из наиболее востребованных методов гибкого создания ПО и определяет правила по управлению процессом производства с использованием известных способов. Акцент в данном случае делают на вовлечении заказчика в разработку (когда завершается очередной этап, возможна смена или уточнение требований к создаваемой продукции). Это позволяет выявить недочеты и откорректировать продукт.

Методология Agile Scrum – одна из популярных технологий

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

Период действия «скрам» небольшой. Участие в этой фазе регби принимают лучшие спортсмены с отличной подготовкой, так как она достаточно травматична. Если подготовленные и сильные игроки отсутствуют, «скрам» попросту не проводят. Методика Scrum в России становится все более распространенной. Остановимся на ней подробнее.

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

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

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

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

  • Scrum Master является посредником между командой и клиентом.
  • Product Owner представляет заказчика, формирует, приоритезирует Product Backlog и принимает промежуточные итоги работы.
  • Team – команда проекта, где отсутствуют отдельные роли. Это самоорганизующаяся система, в которую входят кросс-функциональные мотивированные профессионалы.

Финансистам методология дает ряд преимуществ, а именно:

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

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

Зачем вам нужна Agile методология управления

  • Система позволяет хорошо себя чувствовать в кризисный период и в неопределенных ситуациях, получать доход, защищать свой бизнес, грамотно применять имеющиеся ресурсы и возможности.
  • Agile методологии отдают предпочтение как крупные предприятия, занимающиеся внедрением гибких управленческих методов, так и небольшие компании. Для последних Agile методология – лучший вариант. Речь здесь идет о заведениях общепита, стоматологических клиниках и кабинетах, автосалонах; кроме того, Agile методология позволяет «тюнинговать» бизнес-процессы по таким направлениям, как организация внешнеэкономической деятельности, построение систем продаж и кризис-менеджмент.
  • Применяется Agile методология в менеджменте, маркетинге, финансовой отрасли, управлении персоналом. Благодаря ей можно достичь сверхбыстрой реализации проектов и отличного результата.
  • Agile методология – в первую очередь это гибкое мышление и только потом инструменты. Чтобы успешно пользоваться ею, следует внести определенные изменения в менталитет, культуру работы с проектами на предприятии.
  • В Agile есть множество методов. Самые популярные сегодня – Scrum и Kanban.
  • Agile методология способствует выведению вашего бизнеса на новый уровень с учетом существующих возможностей, ресурсов и практических навыков сотрудников.
  • Agile методология подойдет любому предприятию, ориентированному на получение большего дохода и усиление влияния в рыночной среде.
  • Agile методология обеспечивает поиск и введение новых технологий, связанных с прорывом, развитием внутренней предпринимательской деятельности, креативности подхода и мышления в крупных организациях.

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

Мнение эксперта

Внедрение Agile методологии для повышения эффективности персонала

Мария Онучина,
директор департамента управления объектами компании Becar Asset Management Group, Москва

Мы видоизменили наше офисное пространство, чтобы перейти к управлению по Agile методологии:

Этап 1. Организация рабочих мест.

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

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

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

  • если нужно, побыть в одиночестве;
  • объединиться в мини-группы;
  • провести совещание между отделами в любом составе.

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

Этап 2. Адаптация работников.

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

Этап 3. Введение необычных решений.

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

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

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

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

Результат. Несколько месяцев пребывания в улучшенном офисе показали: работа стала командной, а коммуникация между специалистами разных отделов улучшилась. Удалось сэкономить на аренде. В среднем на человека в офисе масштабной организации приходится 12-40 м2. Ранее у нас было 10 м2, и этот показатель удалось сократить до 6 м2, эффективно распределив рабочие места. Срок окупаемости проекта составил 1,5 года.

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

Какие проблемы могут возникнуть, когда используется Agile методология

Проблема 1. Привычка к роли.

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

Проблема 2. Привычка к документации.

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

Проблема 3. Новая команда.

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

Проблема 4. Проблемы с общением.

Задача менеджера проекта на начальном этапе – проведение митингов с участниками команды для достижения продуктивной и эффективной деятельности.

Проблема 5. Давление по срокам.

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

Проблема 6. Креативность.

Задачи в проекте бывают как интересными, так и не очень. Разработчики зачастую испытывают удовольствие от принятия решений, которые вредят проекту, но интересных технически. Здесь стоит вспоминать о принципах КISS (keep it simple, stupid) и YAGNI (you ain’t gonna need it). Пусть основной характеристикой проектных решений будет простота. Не следует выполнять то, что не особенно нужно в данный момент.

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

Проблема 7. Оценка времени.

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

Проблема 8. Проблема с менеджментом.

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

Проблема 9. Проблемы некомандного поведения.

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

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

Agile методология без ошибок

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

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

Ошибка 2. Неверный диагноз.

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

Ошибка 3. Введение Agile только на отдельном участке бизнес-процессов.

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

Ошибка 4. Занижение важности вовлечения всех сотрудников компании.

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

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

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

Ошибка 6. Нежелание менять кадры.

Практически 90 % успеха зависит от коллектива предприятия. Следует уделять непрерывное внимание развитию, обучению и правильной мотивации сотрудников. Множество специалистов не готовы вести деятельность по Agile методологии, им не интересны новые знания и возможности, освоение бизнес-процессов. Порядка 25-30 % персонала предприятия не желают выкладываться на все сто и стремиться к высокому заработку. Таким сотрудникам лучше сказать: «Прощай». Слабые звенья бывает достаточно сложно выявить, а потому HR-менеджеры зачастую не занимаются этим.

Ошибка 7. Потеря заинтересованности и участия топ-менеджеров.

Обычно на внедрение проекта уходит 8-16 месяцев. В 70 % ситуаций уже по прошествии трех месяцев заинтересованность участников понижается. Как следствие, члены команды просто не хотят входить в состав проекта. Если дела обстоят именно так, решить поставленную задачу вы, конечно, не сможете.

Agile методология: примеры неудачного применения

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

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

И этот пример – не единственный. Брокерам проще: потеряли, а потом заработали в два раза больше. Сложнее дела обстоят у авиакомпаний. Приблизительно такая же ситуация произошла с авиаперевозчиком «Дельта» после простого обновления программного обеспечения. Диспетчерская система перестала получать данные, что привело к вынужденной отмене рейсов. Компания не только потерпела убытки, но и поплатилась репутацией.

Наиболее громкий провал использования Agile методологии связан с запуском системы медстрахования Obama Care в США. Смысл программы состоял в следующем: определенным категориям американских граждан предоставляли бесплатные полисы страхования. Для получения такого права человеку следовало заполнить анкету на сайте и дождаться решения определенных служб. Конечно, миллионы людей бросились заполнять анкеты. Но проблема заключалась в том, что анкету им удавалось заполнить, а отправить ее – нет, возникал какой-то сбой сервера. Система Obama Care прекратила свое действие приблизительно через 6 месяцев после старта. Чтобы наладить работу, заинтересованные лица привлекли специалиста извне, который оценил ситуацию. Консультант проделал огромный путь, начав с конца – «продакшна», собрал части вместе и сумел достичь корректного функционирования системы.

Мнение эксперта

Пример успешного внедрения Agile-управления

Сергей Бучик,
генеральный директор NPM Group, Новосибирск

Фирма, включая все подразделения, переходила на работу по Agile методологии на протяжении 1,5 лет. Ранее в HR-отделе состояли: специалист по кадрам, менеджер по обучению и рекрутер. Руководство подразделений, выбирая новый персонал или проводя обучение, заполняло заявки в огромном количестве. Теперь каждый отдел предприятия имеет свой HR. В группах разработчиков, ведущих деятельность по Scrum методологии, это место отведено Scrum-мастеру. Продукция здесь – это кадровый сервис, а участники коллектива – внутренние потребители.

Новая манера управления по Agile методологии хорошо прижилась в области подбора сотрудников. Заказчик может планировать свою деятельность, учитывая выход кандидата в точно указанное время. В течение 9 спринтов длительностью в 2 недели нам удалось сократить количество просроченных вакансий в 2 раза. Простая вакансия (к примеру, литейщика) теперь закрывается за 20 дней, средняя (сервисного инженера) – 32 дня, редкого специалиста (инженера-технолога по литью пластика) – за 51 день. Завершив первый спринт, рекрутерам стало ясно: для руководства отделов главное – не быстрота поиска, а прозрачные сроки закрытия вакансий и период времени, который они могут потратить на выбор сотрудника с последующим обучением. В настоящий момент менеджер рассказывает заказчику о сроках и стадии поиска соискателя. В обязанности рекрутеров также входит «прокачка» технических компетенций, необходимых для того, чтобы эффективно подбирать производственные вакансии, к примеру, обучение чтению чертежей.

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

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

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

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

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

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

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

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

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

Правило 5. Говорите неэффективным сотрудникам «До свидания», если видите, что Agile методология им не близка.

Правило 6. Не настраивайтесь на идеальное решение задач с первого раза. Порядка 95 % эффективных инструментов и идей удалось достичь после множества повторов и внесения корректировок по прошествии нескольких итераций.

Какие книги про Agile методологию рекомендуется прочесть

1. Эндрю Стеллман, Дженнифер Грин «Постигая Agile».

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

В книге раскрывается суть наиболее востребованных Agile методологий: Scrum, XP (экстремального программирования), Lean (бережливого программирования) и Kanban (Канбан); рассказывается, как использовать их, чтобы создавать качественные программы и достигать поставленных целей. В пособии говорится, как Agile методология помогает менять мышление участников проекта, сплачивать их и вместе стремиться к улучшениям. Цель издания – рассказать о методах Agile, ценностях и принципах, благодаря которым команды могут полностью менять стратегию работы над проектами и подходить к ней иначе. Пособие заинтересует и проектных менеджеров, и руководителей, и просто тех, кто увлекается гибкой методологией разработки Agile.

2. Борис Вольфсон «Гибкое управление проектами и продуктами».

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

3. Джефф Сазерленд «Scrum. Революционный метод управления проектами».

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

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

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

4. Роман Пихлер «Управление продуктом в Scrum».

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

5. Кеннет С. Рубин «Основы Scrum».

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

Важная новость для подписчиков!

Информация об экспертах

Андрей Кочешков, главный аналитик ОАО «Издательство «Просвещение». «Просвещение» — советское, а позже российское специализированное издательство учебной и педагогической литературы.

Мария Онучина, директор департамента управления объектами компании Becar Asset Management Group, Москва. ООО «Бекар-Эксплуатация» (Becar Asset Management Group). Сфера деятельности: системное решение проблем управления объектами (property management), проектами (project management) и инвестициями (брокеридж, оценка). Численность персонала: 5000. Территория: фронт-офисы – в Москве и Санкт-Петербурге; три представительства и 55 обособленных подразделений – в разных городах России.

Сергей Бучик, генеральный директор NPM Group, Новосибирск. ООО «НПМ» (NPM Group). Сфера деятельности: производство оборудования для индустрии напитков; разработка IT-решений для интеграции с оборудованием, мобильных приложений. Численность персонала: более 300. Доля рынка: 95% оборудования по розливу пива и газированных напитков в России. Количество патентов на собственную продукцию: свыше 80.

Читайте в ближайших номерах журнала "Коммерческий директор"

    Читать>>>


    Ваша персональная подборка

      Подписка на статьи

      Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

      Школа руководителя

      Школа руководителя

      Проверьте свои знания и приобретите новые

      Записаться

      Самое выгодное предложение

      Самое выгодное предложение

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

      Живое общение с редакцией

      Выбор редактора

      Дайджест самых нужных статей

      Шеф-редактор журнала «Коммерческий директор» Амина Атавова

      Главный редактор журнала «Коммерческий директор»
      Амина Атавова.

      Читать сейчас

      Рассылка




      © 2011–2016 ООО «Актион управление и финансы»

      Журнал «Коммерческий директор» –
      профессиональный журнал коммерсанта

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

      
      Яндекс.Метрика
      • Мы в соцсетях
      Зарегистрируйтесь на сайте и продолжите чтение! Это бесплатно и займет всего минуту!

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

      • методики, проверенные на практике
      • правовая база
      • полезные подборки статей
      • участие и просмотр вебинаров

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль
      Зарегистрируйтесь на сайте и документ Ваш! Это бесплатно и займет всего минуту!

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

      • методики, проверенные на практике
      • правовая база
      • полезные подборки статей
      • участие и просмотр вебинаров

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль