Система управления agile. Что такое Agile-подход и зачем он нужен бизнесу? Принципы Agile Modeling таковы

Страница 2 из 2

Метод гибкого управления проектом (Agile)

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

Гибкие методы используются тогда, когда присутствуют следующие условия:

• значение проекта четко обозначено,
• клиент активно участвует на протяжении всего проекта,
• клиент, дизайнер и разработчики находятся рядом
• возможна пошаговая разработка, основанная на функциях
• допустима визуальная документация (карточки на стене в противоположность формальной документации). Смотрите Рис. 3

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

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

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

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

Компоненты гибкого метода

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

1. Визуальный контроль. Этот метод планирования основан на карточках, расположенных на стене, которые помогают команде в организации рабочего процесса. К примеру, одна успешная команда расположила на стене карточки различных цветов и видов, которые обозначали элементы конечного продукта. Те элементы, которые были спланированы, разработаны, протестированы и уже выпущены были одного цвета, а те, которые были спланированы, разработаны, протестированы, но еще не выпущены (при этом, уже готовы к выпуску) - были другого цвета. Команда смогла с легкостью изучить положение дел для каждого набора элементов. Визуальный контроль обеспечивает одинаковое виденье проекта каждым из участников.
2. Высокопроизводительные команды, расположенные рядом. Гибкий метод разработки подразумевает, что все участники команды расположены рядом, включая клиента/пользователя, желательно в одной рабочей комнате. Такой подход значительно улучшает качество координирования и сообщения. Тем не менее, это может создать некоторые культурные изменения для разработчиков, ведь поскольку руководители проекта ответственны за собрание высокопроизводительной команды, то члены должны уметь работать, сотрудничая.
3. Разработка, основанная на тестах. В случаях, когда клиенту сложно определить свои требования и нужды, команда разработчиков зачастую использует метод, основанный на тестах продукта. Это требует большого количества шагов между определением нужд, планированием, разработкой и тестированием. Команда почти всегда разрабатывает план тестов, параллельно определяя требования - если требование не удается протестировать, то оно недостаточно разработано. Такой подход может быть использован в традиционном методе разработки, что сделает требования полными, точными и тестируемыми.
4. Адаптируемое управление. Все члены команды постоянно адаптируются под условия. Благодаря динамической среде руководитель проекта должен представлять собой лидера, а не человека, отдающего поручения. Вместо того, чтобы выдвигать жесткие требования группе, он должен установить командные рабочие отношения, определяя основные правила и направления сотрудничества. Участники команды будут приспосабливаться друг к другу на протяжении всего проекта, применяя при этом полученные на предыдущем цикле знания и тем самым улучшая методы, что непременно хорошо скажется на проекте.
5. Совместная разработка. Гибкая методология разработки основана на сотрудничестве среди всех участников команды для получения хороших результатов, объективных мнений и реализации всех полученных знаний на следующем этапе разработки. Это одно из преимуществ данного метода - постоянные объективные мнения и улучшения. Руководитель проекта завершает начальное планирование, а бизнес-аналитик определяет и дает приоритеты элементам разрабатываемого продукта вместе с клиентом и специалистами. Далее, команды проекта сотрудничают, работая над дизайном, разработкой, тестированием и переработкой версии, полученной на каждом предыдущем этапе. Такое сотрудничество с клиентом ведет к успешному проекту.
6. Разработка, основанная на элементах разрабатываемого продукта. Такая система разработки значительно снижает сложность проекта и позволяет командам сфокусироваться на каждом элементе в отдельности. К примеру, одна команда сотрудников работает над элементом #4 - и их волнует только это. Они не заботятся об элементах #1-3. Об этом волнуются бизнес-аналитик и руководитель проекта, который обеспечивает то, что следующий элемент в списке имеет наивысший приоритет, основываясь на его ценности в бизнесе и уровне риска. Зачастую компоненты с высоким риском либо ключевые части инфраструктуры разрабатываются в первую очередь, а затем уже всему остальному дается приоритет на основании значимости в бизнесе. Целью является построение компонентов, основанных на функциональности, но имеющих одностороннюю зависимость с основной системой, поэтому специализированные компоненты являются независимыми друг от друга и могут быть созданы в любом порядке, либо параллельно.
7. Руководство и сотрудничество в противоположность указам и контролированию. Принцип гибкого метода разработки независим от времени и тесно связан с лидерством. Он предусматривает больше шагов к установлению лидерства, чем традиционный метод управления. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта. В дополнение, руководитель проекта исключает все барьеры между командами в проекте.
8. Перевод фокуса с затрат на прибыль. Элементам дается приоритет на основе значимости в бизнесе, к примеру, высокий уровень дохода и доля рынка. В обязанности бизнес-аналитика входит обеспечение того, чтобы команда по разработке проекта не углубилась чересчур в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности. В то время как руководитель проекта заботится о затратах, бизнес-аналитик фокусируется на общей стоимости полного владения продуктом, что включает в себя не только затраты на сам продукт либо его установку, но и последующее использование системы после установки.
9. Усвоение полученных уроков. После каждого цикла команда должна усвоить все полученные навыки и знания для того, чтобы улучшить процесс следующего цикла. Обучаясь, участники адаптируются к работе других коллег и работают вместе над улучшением производительности команды.

Предлагаемые преимущества гибкого метода управления проектом

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

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

Возможно ли использование метода гибкого управления проектом?

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

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

Гибкая методология разработки (англ. Agile software development , agile-методы ) - серия подходов к разработке программного обеспечения , ориентированных на использование итеративной разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики экстремальное программирование , DSDM , Scrum .

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

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

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

Критика

Многие руководители проектов, работающие в традиционных методологиях вроде «водопада », критикуют agile-методы.

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

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

Методологии

Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:

Примечания

Ссылки

• Статья Введение в гибкую разработку программного обеспечения (рус.)
• Статья Гибкий подход разработки ПО - Scrum (рус.)
• Статья Автоматизация тестирования в Agile (рус.)
• Статья Scrum - зачем заказчику знать такие непонятные слова? (рус.)

Литература

• Майк Кон Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). - М .: «Вильямс», 2011. - С. 576. - ISBN 978-5-8459-1731-7

Wikimedia Foundation . 2010 .

Система работы завода «Тойота» уже стала классической и успешной менеджмент-моделью. У каждого работника предприятия была возможность в любое время остановить конвейер в целях устранения дефекта, неполадки или внесения своего рационализаторского предложения. Именно на таком подходе основана философия 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 месяцев после старта. Чтобы наладить работу, заинтересованные лица привлекли специалиста извне, который оценил ситуацию. Консультант проделал огромный путь, начав с конца – «продакшна», собрал части вместе и сумел достичь корректного функционирования системы.

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

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

Сергей Бучик ,

генеральный директор 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 % эффективных инструментов и идей удалось достичь после множества повторов и внесения корректировок по прошествии нескольких итераций.

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.

Такие подходы также иногда называют фреймворками или agile-методологиями.

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

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

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

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

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

Владимир Овелян

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

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Виталий Сотников

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

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

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

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

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

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

Неудобные вопросы

• Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
• Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
• Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

Делай сразу!

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

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

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

Горизонтальная организация

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

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

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

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

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

Как внедрить Agile?

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

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

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