У такого популярного направления в области управления проектами, как Agile конечно же, как и у всего в этом мире есть свои достоинства и недостатки. Если говорить об основных преимуществах Agile методик и практик, это быстрота, адаптивность и фокус на результат. Отсутствие бюрократии и постепенная доставка, шаг за шагом, функционирующего конечного продукта с возможностью вовлекать заказчика, чаще всего показывают более высокую эффективность и более лучшее качество результатов проекта. на изображении четко показано выгоды и преимущества методики Agile для различных направлений т ключевых игроков, которые вовлечены в тот или иной проект. Для команды, это как правило, принятие качественных решений, выбор правильных технологий, выбор способа решения задач, свобода применения и реализации выбранных практик и отсутствие микроменеджмента. Еще одним преимуществом является возможность работать с интересными технологиями, возможность влиять на процессы, продукт в течении всей реализации проекта, ценность для компании и чувствовать увлекательный процесс работы. Быстрая реакция на изменения, еще одно преимущество, в первую очередь для бизнеса, для которого реализуется данный проект, как следствие несет за собой актуальный продукт, способность оперативно корректировать направление развития, создание продукта, который ближе к потребностям пользователя, а также довольных сотрудников получают по итогам заказчики и бизнес. Для клиента методика Agile, это удовлетворение потребностей, это позитивный опыт взаимодействия, это возможность влиять на развитие любимого продукта, постоянное добавление нового функционала и устранение дефектов. Как следствие для всех участников процесса, вовлеченных в реализацию управления проектом высокое качество продукта, высокая скорость внесения изменений, высокий уровень удовлетворения клиентов, мотивированные специалисты, ну и собственно говоря, удовольствие от работы. Помимо преимуществ и достоинств у Agile, как я сказала ранее, есть конечно же и свои недостатки. Снижение важности регламентирующей и технической документации часто может привести к ее нерелевантности, даже к фактичекскому отсутствию, тогда как по итогам выполнения и применения результатов выпущенной продукции на практике так или иначе всегда нужна документация, поэтому важно помнить , когда мы много говорим о том, что Agile отрицает бюрократию, большое количество документации, важно помнить, что здесь скорее фокус на большом количестве документации и лишней документации. То есть, Agile сам по себе не отрицает наличие необходимой документации, как технической, так и регламентирующей, которая поможет эффективно заказчику применять результат выпущенной продукции на практике. Краткосрочное планирование, как особенность всех Agile методик не всегда учитывает масштабирование продукта, что часто может за собой понести некие архитектурные заминки или корректировки во времени выпуска финальной продукции. Например, если мы сфокусированы на выпуске оного ПО для конкретной фирмы, в какой-то момент заказчик говорит, что это будет 10 фирм или 100 фирм по всему миру, мы это не учитываем заранее тем самым увеличиваем, уже в процессе, количество затраченного времени на выпуск готового продукта. Тоже важно помнить и когда мы создаем бэклог, то есть, когда записываем весь конечный продукт, важно при взаимодействии с заказчиком учитывать планирует ли он масштабировать то что мы будем выпускать или все-таки это будет разовый продукт. Появление новых требований после нескольких итераций может привести к изменениям изначального бэклога, продукта и увеличению количества итераций по созданию конечного продукта. Часто накопленные дефекты и снижение качества разрабатываемого продукта несут за собой, как следствие, выбор простых и быстрых способов их устранения, но не всегда самых правильных. Вы наверняка слышали или читали, где-то и сталкивались с таким понятием, как «горизонтальная организация». Важно знать, что это понятие тоже пришло в мир менеджмента и управления проектами из Agile методик. Любая Agile-команда строится на принципах самоорганизации и равной ответственности всех членов команды друг перед другом. Даже человек, которого в Российских, на самом деле, больше реалиях, принято считать лидером, руководителем проекта по Agile методики, его называют держателем продукта (Product Owner), он на самом деле не является руководителем проектов согласно методикам Agile, его задача персонифицировать продукт. Он лишь является носителем знания о том каким должен быть конечный результат продукта, но никаким образом, сточки зрения классического менеджмента не является руководителем тех других членов команды, которые также работают над созданием продукта. Однако, как я уде сказала в Российских реалиях, привычка чувствовать себя внутри иерархичной системы, пока еще трудно искоренима, часто в рамках Agile-проектов, Product Owner берут на себя и роль управленца. Хотя в классике Product Owner и все остальные члены Agile-команды равны и ответственны друг перед другом. Еще одной ценностью Agile-команд является взаимопроникновение знаний. Это про то, что каждый член команды не должен замыкаться конкретно на своей узкой области знаний в рамках, которой он попал в Agile-проект, но ему следует стремиться и кросс-функциональным знаниям в рамках создания того или иного продукта. Не стоит утрировать, это не значит, что продавец должен быть программистом или маркетолог должен четко знать каким образом создается ПО. Нет. Но при этом, вот если мы с вами посмотрим на соотношение своих узких знаний и кросс-функциональных знаний, методики Agile говорят нам о том что важно чтобы и дизайнер, и маркетолог, и программист не зацикливались четко на своей области знаний, но и погружались в, хотя бы информационно, с точки зрения получения знаний, в другие направления, которые влияют на создание конечного продукта. Такое перекрестное наполнение каждого члена Agile-команды дополнительными знаниями в рамках проекта называется — T-shape. Мы с вами можем, на изображении, видеть почему, то есть глубина экспертизы по своей области она, конечно же гораздо шире нежели чем дополнительные знания и навыки. Однако, как раз вот эта кросс-функциональность и владение знаниями и навыками в соседних областях, которые также влияют на создание конечного продукта, максимально важно для нас, потому что мы помним, что один из принципов основополагающих Agile методик — это эффективное взаимодействие людей и команды, и для того чтобы все понимали о чем говорит программист, дизайнер и маркетолог, как раз и создалась T-shape модель, когда фокусировка членов Agile -команды идет не только на их экспертные области, но и на другие области, которые проникают и влияют на создание продукта. Agile сегодня применяется не только в IT-направлениях различных компаний, но и стартапах, которые посвящены, как техническим разработкам, так и в гуманитарном или маркетинговом. Также крупные компании, Российские, сегодня, прибегают к Agile-методикам для повышения эффективности внедрения тех или иных продуктов с точки зрения развития бизнеса или выхода на новые рынки. В банковском секторе в России, достаточно активно используются сегодня Agile-методики и в Центробанке, и в Сбербанке, и Райффайзенбанк Российский прибегают к методикам с целью повышения вовлеченности сотрудников, скорости достижения тех или иных результатов бизнеса, а также улучшению прозрачности и управлению изменениями. Сегодня в России, когда все говорят о цифровизации и диджитализации принципы Agile используются не только банковским или коммерческим сектором, но и правительственные и государственные компании также прибегают к Agile-методикам с целью внедрения быстрого и эффективного решения или решений в области применения качественный коммуникационных, технологических решений.
