Гибкие технологии управления проектами. Agile. Как и когда применять этот метод. Плюсы и минусы Agile

Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

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

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

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

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

Agile-манифест разработки программного обеспечения:

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

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

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт - основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота - искусство минимизации лишней работы - крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Критика Agile

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

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

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

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

• эпики (epics) - это просто проекты
• пользовательские истории (user stories) - это просто сценарии использования (use case)
• спринты (sprints) - это просто работа
• стенд апы (stand-ups) - это просто совещания
• итерации (iterations) - это просто версии
• бэклоги (backlogs) - это просто список дел
• скорость команды (velocity) - это просто результаты
• и эти задачи (tasks) - это реально, просто задачи

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

Разновидность методологий гибкой разработки

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

• Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
• Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
• Agile Data Method (ADM) - набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
• Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
• Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
• Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
• Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
• Getting Real (GR) - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
• OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
• lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
• Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

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

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

Большой взрыв проектов

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

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

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

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

Манифест Agile

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

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

Как устроены процессы

Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum - сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum» , изобрел эту методику, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта - это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой - от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

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

4. Составьте бэклог продукта - соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, - .

5. Запланируйте спринты - отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

6. Проводите ежедневные встречи на 15 минут (и ни минутой больше) - на повестке три вопроса, на которые коротко отвечает каждый: что делал вчера, что буду делать сегодня и какие преграды мешают «взять высоту».

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

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

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

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

Знать Agile в лицо

Agile-методики легко опознать по ключевым характеристикам, эдаким «сигнальным флажкам».

1. Минимизация рисков - это главная цель в рамках любого гибкого подхода.
2. Итеративная разработка - работа в коротких циклах.
3. Люди и коммуникация - самое важное.

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

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

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

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

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

Кому это может не понравиться?

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

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

P.S. Хотите каждую неделю получать полезные советы из самых интересных книг по бизнесу и маркетингу, узнавать о новинках и получать скидки? Подписывайтесь на нашу рассылку. В первом письме - подарок.

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

Agile, появившийся как метод разработки ПО в небольших командах лет 10-15 назад, сегодня становится новой культурой управления большими компаниями. Благодаря недавнему выступлению Германа Грефа термин Agile входит в лексикон всех современных российских менеджеров.

Что же такое Agile и почему этот метод называют чуть ли не единственно правильным?

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

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

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

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

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

Безусловно, есть организации, которым Аgile вовсе не нужен. Например, государственные ведомства. Их деятельность основывается на законодательстве. Мы не сможем взаимодействовать с государством, если правила игры меняются каждый день.

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

Переход большого классического бизнеса (Enterprise) к Agile

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

Передовой бизнес базируется на трех китах: опыт и знания в индустрии (в которой работает бизнес), разработка продуктов и сервисов по методологии Agile и самое главное - инновационная культура.

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

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

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

Гибкое планирование

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

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

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

Читайте материал

Если заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на "Как рассказать бабушке" или "Как рассказать дедушке" и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

"Что с этим нам делать то, у нас из программирования только сайт?"

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс - в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

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

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

Команда в игре "Что? Где? Когда?" существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

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

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

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

Но . Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

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

Итого ключевые ценности Agile (манифест):

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

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration). Если идет обсуждение вопроса "Как реализовать продукт?" на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: "Как управлять ресурсами когда все так гибко?"

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:
"А как точнее управлять ресурсами?", "Как раньше понять, что в проекте ресурсов стало не хватать для окончания?", "Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?". Что бы рассказать про Agile, можно раскрыть только этот вопрос.

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

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

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) - это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте - это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, "Выпуск досок с правами" или "Выпустить сайт на тест". Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь - это график с двумя линиями; первая - сколько времени сгорело и это всегда прямая, на второй - сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка - попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход - заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России - они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения - это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование - спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом - хорошая практика. Спринт - это несколько недель. Слишком короткие или слишком длинные отрезки - плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача - чтобы каждый день команда подтверждала единое направление движение всех участников. По классическому описанию каждый в команде раскрывает три вопроса:

• Что сделано к этому моменту из спринта?
• Что планируется на сегодня?
• Какие проблемы возникли или что мешает?

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

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

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило в виде выступления. Главный смысл в том, чтобы была "сессия" и ничего страшного, если это станет похоже на отчетность перед руководством. Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании. Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

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

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

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

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

Однажды в Россию на завод по сбору автомобилей знаменитой корпорации Тойота приехал топ-менеджер.

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

В основе всего лежала agile методология. Но то что он увидел на совещании повергло его в шок…

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

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

Начался гул, обсуждения, препирательства. Руководитель по маркетингу начал спорить с руководителем по продажам.

Так прошло минут 15. И тут директор с криком “Демократия кончилась, теперь снова диктатура!” начал раздавать распоряжения, который подчиненные стали усердно записывать в свои ежедневники.

Гость из Японии от увиденного смог вымолвить всего одну фразу: “Но это же не agile управление проектами.

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

Я уж не говорю про идеи на планерках…”. На что генеральный ответил: “Да, это не принципы аджайл! В России такие гибкие методы не работают!”.

Ну не работают они…

Скорей всего у Вас тоже в голове сейчас крутится вопрос: “Что же это за загадочная такая фраза?”.

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

Виноваты программисты

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

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

1. Идея;
2. Техническое задание;
3. Создание дизайна;
4. Программирование;
5. Тестирование;
6. Запуск итоговой версии.

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

В результате при создании дизайна или программировании, новые идеи просто приходилось игнорировать.

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

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

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

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

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

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

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

Именно это собрание в горной деревушке Сноубёрд в феврале 2001 года и считается зарождением методологии agile (кто-то даже называет это философией).

Поскольку в большинстве своем эти люди были программисты, то результатом собрания был выпуск “Манифеста гибкой методологии разработки программного обеспечения” (по английски Agile Manifesto) и принципов Аджайла.

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

Коротко и по делу

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

1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Принципы, упоминающиеся в манифесте Agile. Просто прочтите, поймёте чуть дальше.

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

“Что за чушь я только что прочитал? Ни слова не понял!”. Думаю у Вас такие сейчас мысли.

Скажу честно, что такое Agile как методология (а также что написано в манифесте) я сам понял далеко не сразу, книги и статьи давали поверхностное описание, пока я не увидел всё это на практике.

Поэтому я сэкономлю Вам огромное количество времени и расскажу коротко и по делу.

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

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

На примере всё ясно

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

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

Обычный хлебзавод в России

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

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

После исследований технолог разработает хлеб на свой вкус и приносит его директору.

Он пробует новый продукт и решает - наградить технолога словами “Молодец. Держи бублик” или сказать “Нет. Переделывай”.

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

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

Agile-хлебзавод в России

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

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

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

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

ВНЕДРЯТЬ ИЛИ ПОСЛАТЬ

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

Что в результате хорошо скажется на продажах, сэкономит массу времени и отведёт от ошибок.

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

Но это в корне не верно. В России эту методологию активно использует:

• Банк “Альфа-банк”;
• Сеть пиццерий “Додо пицца”;
• Бухгалтерский сервис “Кнопка”.

И если с “Альфа-банком” все понятно, большая компания, у них есть ресурсы и люди для внедрения инноваций в свою систему.

То с “Додо пицца” и “Кнопка” всё намного интереснее, ведь компании небольшие. И по моему мнению именно одним из факторов их успеха стал этот подход.

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

1. Благодаря применению “гибких” подходов возрастает качество получаемых результатов;
2. Результаты получаются гораздо быстрее и эффективнее за счет чего экономится время и затраты;
3. Компания лучше адаптирована к изменениям (даже непредвиденным) и конкуренции;
4. Создание проектов происходит более планируемо и контролируемо;
5. Компания может создавать продукты, которые будут ждать и покупать их потребители.

Внутренняя работа

Единственный вопрос, на который я долго искал ответ, как же тогда происходит работа в agile-компании.

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

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

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

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

3. Тестирование. Все идеи и знания суммируются в тестовый рецепт. Данный рецепт выпекается небольшой пробной партией для получения по нему обратной связи на закрытой дегустации среди обычных покупателей (!!!).
4. Сбор обратной связи. Покупатели едят хлеб и высказывают свои пожелания. На основании этого в тестовый рецепт вносятся изменения и доработки. Финал.

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

Хочу себе

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

И Вы думаете, что agile это то, что Вам так нужно. Ведь так можно создать что-то новое, поистине инновационный продукт.

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

Это топ-5 вопросов, которые задают себе все собственники, когда видят эту методологию.

Подходит малому бизнесу? Если Вы не выпускаете постоянно новые продукты или не реализуете постоянно новые проекты, а работаете на “старом”, то с большей долей вероятности НЕТ.

Легко ли внедрить? Отвечу вопросом на вопрос: А легко выучить иностранный язык? Философию нельзя быстро внедрить в компанию. Ее нужно внедрять пошагово и в течение довольно долгого времени.

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

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

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

Кто должен быть начальником? Прозвучит непривычно, но в agile-компаниях нет начальников.

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

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

НАС УЖЕ БОЛЕЕ 29 000 чел.
ВКЛЮЧАЙТЕСЬ

Подводные камни

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

Их осознают компании только после внедрения. Поэтому заранее “Пожалуйста” за то, что спас Вас от потери денег и времени.

Аджайл - не инструмент

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

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

Сюда включается или Скрам (инструменты управления). О каждом инструменте в дальнейшем мы конечно же напишем статьи, но Вы должны понять, что аджайл это прежде всего философия, принятая в компании.

Команда

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

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

И именно команда будет оценивать вклад каждого конкретного специалиста в проект. А это очень сложно, если у Вас не топовые спецы своего дела.

Чужой нос

Личного пространства в компании больше нет. Из серии - я к тебе не лезу и ты ко мне не лезь. Этого больше нет.

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

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

Оплата

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

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

Текучка

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

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

Коротко о главном

Для кого все таки подойдут методы управления проектами agile? Для больших компаний или для маленьких? На самом деле и для тех, и для других.

Большие компании от них “молодеют”, становятся более подвижными и менее бюрократичными, небольшим же компаниям они дают мощный рывок.

Ведь Вы перестаете работать по-старинке, а Ваши сотрудники перестают думать (и работать) как большинство Ваших конкурентов.

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

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

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

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