Agile подход на практике: применение и ограничения


Привет!


Сегодня мы поговорим с вами об Agile подходе. Теоретически работает любой подход к управлению проектами и командами. На практике оказывается, что это не совсем так, как в теории. У гибких методов есть свои ограничения, и на практике гибкость не всегда важнее, чем классическая модель управления проектами. Где гибкие методологии имеют свои ограничения? Где классика (PMBOK) полезнее? Может, их можно помирить? Об этом поговорим сегодня.


Как вы относитесь к гибкому подходу? Когда его стоит использовать и о чем стоит помнить? Начнем по порядку.


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

- делать значимую работу,

- в благоприятной среде,

- по дружески,

- на основе быстрого цикла PLAN - DO - CHECK - ACT (цикл Деминга)


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


Есть ли у гибкого подхода свои ограничения?


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


Прежде всего, Agile - это люди

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


То, что слева, так же важно, как и то, что справа

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


Фанатизм - «если вы не используете SCRUM, значит, вы не Agile»

Отрицание того, что было до Agile, потому что Agile крутой и необычный, и вы ничего не знаете, - не самый умный подход. Это неправда, если вы не делаете что-то, как написано в Scrum Guide. (Scrum - очень популярный стандарт в разработке программного обеспечения, а не в управлении проектами), значит, вы не Agile. Было удивительно, когда я продемонстрировал свой Agile-подход, когда мы работали, когда SCRUM еще не был так популярен, я получил ответ, что у вас нет артефактов, которые есть в SCRUM. И что? Речь идет о соблюдении правил, а не о конкретном методе. Как и в большинстве случаев, SCRUM отлично подходит для разработки программного обеспечения в определенных обстоятельствах, но во многих ситуациях он не работает.


Привычки, привычки, структура, организация

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


В некоторых компаниях, где меня попросили проконсультировать, было невозможно применить 100% Agile подход, и уж тем более SCRUM, потому что структура этого не позволяла. Однако вы можете мыслить гибко. Только не все элементы можно реализовать. 

Важно, чтобы это не было поводом для разочарований.


Организация .. Спросите любого, как вы работаете с государственным управлением, когда дело касается выполнения определенных контрактов. Это непростая задача по разным причинам. Не все можно сделать гибко, если вся система невиновна. И это все. Некоторые вещи просто не прыгают. Однако, несмотря на эти ограничения, стоит хорошо подумать о своей работе и своем подходе. Он понимал, что если были объективные причины, иначе и быть не могло. Очень часто чего-то не хватает, это реальность. Я еще не столкнулся с идеальной ситуацией. Очень редко компания организована таким образом, чтобы владельцы уже работали с гибким подходом, и именно так они создали структуру и работают над разработкой программного обеспечения, и это заложено в ДНК компании. 


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


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


Когда следует использовать гибкий подход?


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


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


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


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


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


Управление командой и проектом - аналогично.

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


В итоге, что нужно помнить:


Agile - это философия, способ думать о бизнесе, проектах и ​​командной работе.


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


Успехов вам и до новых встреч!


Старт интенсива по управлению рисками 2020!

Запишитесь первыми на 3х дневный интенсив по управлению рисками


 Узнать подробнее и записаться по спец условиям >> 


Похожие статьи:

Бесплатная диагностика бизнеса


Получите в подарок:

Чек-лист "Планирование проектов"



Excel книгу "Учет и планирование финансов 2020"