The measure of intelligence is
the ability to change.
Albert Einstein
Представляю ИТ-сообществу “Размышления о Agile” или можно назвать данную статью так, “Agile, это все же философия или проектная методология?”.
Цель данной статьи — обсудить с ИТ-сообществом вопрос о Agile, который у меня возник после многолетней проектной практики, выводы и резюме, к которому пришел, по результатам анализа этого вопроса.
Сам Вопрос привожу несколько ниже, так как, чтобы к нему перейти, имеет смысл изложить некоторые доводы и выводы.
Похожие темы уже поднимались на Хабре в различных ветках обсуждения, так что вопрос насущный и имеет свою историю.
На мой взгляд большинство статей не дает однозначного ответа на мой вопрос, поэтому настоящая статья, возможно, будет интересна многим.
Несколько статей на Хабре по теме:
Чтобы немного было понятно откуда “дует ветер”, отмечу, что мой опыт в ИКТ сфере более 10 лет. В самом начале карьеры активно трудился в телекоме, в софтверной разработке работаю сравнительно недавно, не более четырех лет.
На всем протяжении своей трудовой деятельности участвовал во всевозможных ИТ и Телеком проектах, в роли Руководителя проектов, последние годы был и бизнес-аналитиком, пробовал себя и в роли программиста. В результате краткого но объемного погружения в Java — development получил не большой, но все же, опыт самостоятельной разработки, прокачав технические скилл как младший-программист.
Сейчас же активно тружусь на ниве разработки программных продуктов как Руководитель проектов, опционально выступая как Бизнес — аналитика.
Таким образом предмет обсуждения этой статьи — это практика управления проектами по разработки программных продуктов, причем применительно именно к отечественной разработке.
На протяжении своего проектного опыты в ИКТ, вывел для себя ключевое правило: управлять проектом с применением проектной методологии — хорошо, без методологии — непонятно.
В связи с выше озвученным пришел к необходимости изучения различных проектных методологии, методологий ITSM, разных бизнес-книг по теме, и просто “умных” и сложных книг.
С учетом популярности PMI в общем и моей родной телеком отрасли в частности, начал изучение с PMBoK. Хотя и не сразу был понят этот хитрый талмуд, не единожды при прочтении очередной главы мне приходилось задуматься над тем, что же всетаки курят составители книги. В итоге свод знаний был разложен на атомы и принят в полном объеме. К слову сказать, даже не однократно внедрен в ряде проектов с “пролетарским рвением”, терпением и проворством (внедрен не PMBoK конечно, а его инструменты).
Понимание PMBoK, приходит с опытом.
@PM
Кроме этого “эпичного” труда были исследованы и изучены другие методологии, были и просто авторы книг по проектному менеджменту (хотя такие личности как Т. Демарко, С. Беркун, С Макконел не просто авторы, а нечто все же большее), всех перечислять не имеет смысла, да и статья не об этом.
Подытожим, автор статьи в теме предмета, старается не отставать от мировых трендов, не забывает классику.
Заскучал в телекоме через восемь лет работы, и решив идти вперед, ринулся в ИТ.
Оказалось, что ИТ сфера не хочет жить в четких рамках классических “водопадов”, ГОСТ 34 не в моде, если конечно не брать в расчет Гос. сектор. Есть и другие тренды по управлению проектами, в мировом проектном менеджменте.
Agile-манифест не мог пройти мимо. Изучив ряд книг и пообщавшись с несколькими коллегами, решил, что Agile это, как минимум интересно. Но не совсем понятно как с этим работать в России, философия не дотягивает до методологии, а в нашей стране есть народная мудрость “что не запрещено, то разрешено”.
Как резюме: пришел к выводу, Agile конечно штука интересная, но все же, подходит пока больше для модных книг и небольших проектов, а как это внедрить на практике не ясно.
Анализ статей на Хабре, в общем-то, подтвердил краткое резюме приведенное выше.
После нескольких итераций изучения Agile по книгам, мне “повезло”, мне довелось участвовать в нескольких отечественных Agile — проектах.
От такого Agile стало совсем не весело, а РП с опытом планирования и управления проектами из телеком отрасли просто загрустил совсем. При попытках взять под контроль стихийную разработку таких молодцев, все ломается совсем, а ребята в унисон глаголят: “Мы творческие, у нас Agile, не мешайте жить/работать/развиваться”. Учиться и думать не хотят, у них только Agile в голове.
Но не смотря на мой скептический взгляд, Agile шествовал по стране, его активно продвигал Г. Греф и исповедовали разные западные и отечественные гуру ИТ-отрасли.
Но, как и показал личный опыт, Agile все используют по своему, с нашим то менталитетом мы просто создали “Agile по русски”.
Как итог, вопрос рос и креп, а ответ мне на него никто дать не мог.
Что же все таки такое этот Agile, философский стэк идей по психологии и организации труда, сумасбродства разума, и не желания работать по правилам, или за этим все же скрывается что то более серьезное с методологической точки зрения, то что можно применить и у нас на родине, на серьезных проектах, что то стоящее внимания?
Перед завершением этого раздела есть несколько моментов которые стоит отметить:
Книга Лоуренса Лича, “Вовремя и в рамках бюджета”
Интересная книга о проектном менеджменте по методу “Критической цепи”, автора можно отнести к идеологам тяжелого менеджмента. Книга Л. Лича описывает непростой, но крайне интересный подход по применению теорий Э. Деминга и Э.Голдратта в проектном планировании.
С учетом приобретенных теоретических и практических знаний, крепло понимание о незаконченности в понимании Agile как методологии для ее адекватной реализации в отечественных проектах.
Правильный Agile или адаптивный PMBoK от Майка Кона.
Совершенно случайно, или как говорится ”вдруг откуда не возьмись”, мне попалась очередная книга про Agile. Это книга за авторством некоего Майка Кона (Cohn Mike) под названием “Agile. Оценка и планирование проектов”.
В начале предположил, что это очередная бизнес-книга описывающая, что Agile это круто, модно, молодежно.
Так и было и решил ознакомившись с предисловием, но уже при прочтении первой главы стало интересно, кто же это такой, этот Майк Кон, и почему он пишет такие правильные вещи.
Краткая справка, кто такой Майка Кона (Cohn Mike)
Основатель Mountain Goat Software, фирмы, занимающейся консалтингом в сфере управления процессами и проектами. Он специализируется на помощи компаниям в применении agile-подхода с целью повышения эффективности. За спиной у Майка более чем 20-летний опыт работы руководителем в организациях разного размера, от стартапа до компании из списка Fortune 40. Является соучредителем организации Agile Alliance и входит в ее совет директоров.
Не планирую описывать в этой статье книгу полностью, так как лучше ее прочитать самам (тем кому нужно), но обозначу главное, книга Майка это переработанный PMBoK PMI с учетом философии Agile-манифеста.
Сразу обращу внимание, что Майк не написал очередной свод знаний, скучный и непонятный, он не копировал PMBoK. Вместо этого Майк Кон создал интересную, легко читаемую и нужную книгу:
В книге описан весь жизненный цикл проекта, особое внимание уделено этапу Планирования проекта, описаны очень интересные и здравые методы и подходам к планированию и оценки работ, а также описаны подходы и инструменты этапов Исполнения проекта, этапа Мониторинга и контроля.
Несмотря на то, что книга меня и так поразила по своей функциональности, применимости и методологической зрелости, так Майк еще и применил крайне интересный и сложно описанный метод по митигации рисков неопределенности, который описывает в своей книги Лоуренс Лич. При всем вышеописанном Майк предлагает простым и понятным языком как можно внедрить и расширить этот метод на практике.
Чтобы построить любой процесс, нужны правила, нормы и принципы, Майк их для нас описал.
На мой взгляд, перед нами с 2001 г. стоят несколько интересных вопрос:
Нужна ли нам в философии Agile, методология, или нам достаточно принципов?
Хотим ли мы разрабатывать качественное ПО эффективно и понятно, или оставим эту прерогативу избранным, и продолжим “выдумывать велосипед”?
Книга Майка, на мой взгляд, определяет правила, от которых многие хотят уйти, но как показывает опыт, правила все равно нужны.
Кроме описанного выше, книга Майка дает четкие методологические указания (хотя кому-то это слово может и не нравится), о том как должно быть построено управление проектами софтверной разработки по Agile.
В любом случае, все у нас будет так, как будет, но ясно одно, правила и принципы нужны во всем, и в Agile они есть.
Эти принципы описаны и зафиксированы, их можно изучать, ими можно пользоваться.
Чтобы финализировать свое резюме, обозначу следующее:
Ageli не в кризисе, Agile не проблема, Agile работает.
Вопрос только в том, хотим ли мы изучать правила и делать как они предписывают или мы хотим продолжать работать так как хотим.
Never lose a holy curiosity.
Albert Einstein
P.S.
Уважаемые читатели, кто все же дочитал статью, мне очень интересно Ваше мнение и комментарии, а также рекомендации по аналогичным книгам, таким как книга Майка Кона.
the ability to change.
Albert Einstein
Предисловие
Представляю ИТ-сообществу “Размышления о Agile” или можно назвать данную статью так, “Agile, это все же философия или проектная методология?”.
Цель данной статьи — обсудить с ИТ-сообществом вопрос о Agile, который у меня возник после многолетней проектной практики, выводы и резюме, к которому пришел, по результатам анализа этого вопроса.
Сам Вопрос привожу несколько ниже, так как, чтобы к нему перейти, имеет смысл изложить некоторые доводы и выводы.
Похожие темы уже поднимались на Хабре в различных ветках обсуждения, так что вопрос насущный и имеет свою историю.
На мой взгляд большинство статей не дает однозначного ответа на мой вопрос, поэтому настоящая статья, возможно, будет интересна многим.
Несколько статей на Хабре по теме:
- Agile: крупнейшая идеологическая проблема в IT.(19 апреля 2019 )
- Почему Agile не работает и что с этим делать. (20 декабря 2017)
- Кризис Agile. Что делать? (23 июня 2019)
Кратко о предмете вопроса
Чтобы немного было понятно откуда “дует ветер”, отмечу, что мой опыт в ИКТ сфере более 10 лет. В самом начале карьеры активно трудился в телекоме, в софтверной разработке работаю сравнительно недавно, не более четырех лет.
На всем протяжении своей трудовой деятельности участвовал во всевозможных ИТ и Телеком проектах, в роли Руководителя проектов, последние годы был и бизнес-аналитиком, пробовал себя и в роли программиста. В результате краткого но объемного погружения в Java — development получил не большой, но все же, опыт самостоятельной разработки, прокачав технические скилл как младший-программист.
Сейчас же активно тружусь на ниве разработки программных продуктов как Руководитель проектов, опционально выступая как Бизнес — аналитика.
Таким образом предмет обсуждения этой статьи — это практика управления проектами по разработки программных продуктов, причем применительно именно к отечественной разработке.
Понимание вопроса автором
На протяжении своего проектного опыты в ИКТ, вывел для себя ключевое правило: управлять проектом с применением проектной методологии — хорошо, без методологии — непонятно.
В связи с выше озвученным пришел к необходимости изучения различных проектных методологии, методологий ITSM, разных бизнес-книг по теме, и просто “умных” и сложных книг.
С учетом популярности PMI в общем и моей родной телеком отрасли в частности, начал изучение с PMBoK. Хотя и не сразу был понят этот хитрый талмуд, не единожды при прочтении очередной главы мне приходилось задуматься над тем, что же всетаки курят составители книги. В итоге свод знаний был разложен на атомы и принят в полном объеме. К слову сказать, даже не однократно внедрен в ряде проектов с “пролетарским рвением”, терпением и проворством (внедрен не PMBoK конечно, а его инструменты).
Понимание PMBoK, приходит с опытом.
@PM
Кроме этого “эпичного” труда были исследованы и изучены другие методологии, были и просто авторы книг по проектному менеджменту (хотя такие личности как Т. Демарко, С. Беркун, С Макконел не просто авторы, а нечто все же большее), всех перечислять не имеет смысла, да и статья не об этом.
Подытожим, автор статьи в теме предмета, старается не отставать от мировых трендов, не забывает классику.
Deep dive in project management of Software
Заскучал в телекоме через восемь лет работы, и решив идти вперед, ринулся в ИТ.
Оказалось, что ИТ сфера не хочет жить в четких рамках классических “водопадов”, ГОСТ 34 не в моде, если конечно не брать в расчет Гос. сектор. Есть и другие тренды по управлению проектами, в мировом проектном менеджменте.
Agile-манифест не мог пройти мимо. Изучив ряд книг и пообщавшись с несколькими коллегами, решил, что Agile это, как минимум интересно. Но не совсем понятно как с этим работать в России, философия не дотягивает до методологии, а в нашей стране есть народная мудрость “что не запрещено, то разрешено”.
Как резюме: пришел к выводу, Agile конечно штука интересная, но все же, подходит пока больше для модных книг и небольших проектов, а как это внедрить на практике не ясно.
Анализ статей на Хабре, в общем-то, подтвердил краткое резюме приведенное выше.
После нескольких итераций изучения Agile по книгам, мне “повезло”, мне довелось участвовать в нескольких отечественных Agile — проектах.
От такого Agile стало совсем не весело, а РП с опытом планирования и управления проектами из телеком отрасли просто загрустил совсем. При попытках взять под контроль стихийную разработку таких молодцев, все ломается совсем, а ребята в унисон глаголят: “Мы творческие, у нас Agile, не мешайте жить/работать/развиваться”. Учиться и думать не хотят, у них только Agile в голове.
Но не смотря на мой скептический взгляд, Agile шествовал по стране, его активно продвигал Г. Греф и исповедовали разные западные и отечественные гуру ИТ-отрасли.
Но, как и показал личный опыт, Agile все используют по своему, с нашим то менталитетом мы просто создали “Agile по русски”.
Как итог, вопрос рос и креп, а ответ мне на него никто дать не мог.
Что же все таки такое этот Agile, философский стэк идей по психологии и организации труда, сумасбродства разума, и не желания работать по правилам, или за этим все же скрывается что то более серьезное с методологической точки зрения, то что можно применить и у нас на родине, на серьезных проектах, что то стоящее внимания?
Перед завершением этого раздела есть несколько моментов которые стоит отметить:
- После выхода 6-го издания PMBoK в 2018 г. вопрос о Agile стал еще более занимательный (в 6-ом издании авторы включили кейсы с применением Agile).
- Мне попалась для прочтения книга Лоуренса Лича, “Вовремя и в рамках бюджета”.
Книга Лоуренса Лича, “Вовремя и в рамках бюджета”
Интересная книга о проектном менеджменте по методу “Критической цепи”, автора можно отнести к идеологам тяжелого менеджмента. Книга Л. Лича описывает непростой, но крайне интересный подход по применению теорий Э. Деминга и Э.Голдратта в проектном планировании.
С учетом приобретенных теоретических и практических знаний, крепло понимание о незаконченности в понимании Agile как методологии для ее адекватной реализации в отечественных проектах.
Эндшпиль
Правильный Agile или адаптивный PMBoK от Майка Кона.
Совершенно случайно, или как говорится ”вдруг откуда не возьмись”, мне попалась очередная книга про Agile. Это книга за авторством некоего Майка Кона (Cohn Mike) под названием “Agile. Оценка и планирование проектов”.
В начале предположил, что это очередная бизнес-книга описывающая, что Agile это круто, модно, молодежно.
Так и было и решил ознакомившись с предисловием, но уже при прочтении первой главы стало интересно, кто же это такой, этот Майк Кон, и почему он пишет такие правильные вещи.
Краткая справка, кто такой Майка Кона (Cohn Mike)
Основатель Mountain Goat Software, фирмы, занимающейся консалтингом в сфере управления процессами и проектами. Он специализируется на помощи компаниям в применении agile-подхода с целью повышения эффективности. За спиной у Майка более чем 20-летний опыт работы руководителем в организациях разного размера, от стартапа до компании из списка Fortune 40. Является соучредителем организации Agile Alliance и входит в ее совет директоров.
Не планирую описывать в этой статье книгу полностью, так как лучше ее прочитать самам (тем кому нужно), но обозначу главное, книга Майка это переработанный PMBoK PMI с учетом философии Agile-манифеста.
Сразу обращу внимание, что Майк не написал очередной свод знаний, скучный и непонятный, он не копировал PMBoK. Вместо этого Майк Кон создал интересную, легко читаемую и нужную книгу:
- Описал принципы и правила, которые должны быть в Agile;
- Описал инструменты планирования и оценки работ;
- Дал представление и грамотном управлении разработкой;
- И многое другое.
В книге описан весь жизненный цикл проекта, особое внимание уделено этапу Планирования проекта, описаны очень интересные и здравые методы и подходам к планированию и оценки работ, а также описаны подходы и инструменты этапов Исполнения проекта, этапа Мониторинга и контроля.
Несмотря на то, что книга меня и так поразила по своей функциональности, применимости и методологической зрелости, так Майк еще и применил крайне интересный и сложно описанный метод по митигации рисков неопределенности, который описывает в своей книги Лоуренс Лич. При всем вышеописанном Майк предлагает простым и понятным языком как можно внедрить и расширить этот метод на практике.
Чтобы построить любой процесс, нужны правила, нормы и принципы, Майк их для нас описал.
Резюме
На мой взгляд, перед нами с 2001 г. стоят несколько интересных вопрос:
Нужна ли нам в философии Agile, методология, или нам достаточно принципов?
Хотим ли мы разрабатывать качественное ПО эффективно и понятно, или оставим эту прерогативу избранным, и продолжим “выдумывать велосипед”?
Книга Майка, на мой взгляд, определяет правила, от которых многие хотят уйти, но как показывает опыт, правила все равно нужны.
Кроме описанного выше, книга Майка дает четкие методологические указания (хотя кому-то это слово может и не нравится), о том как должно быть построено управление проектами софтверной разработки по Agile.
В любом случае, все у нас будет так, как будет, но ясно одно, правила и принципы нужны во всем, и в Agile они есть.
Эти принципы описаны и зафиксированы, их можно изучать, ими можно пользоваться.
Чтобы финализировать свое резюме, обозначу следующее:
Ageli не в кризисе, Agile не проблема, Agile работает.
Вопрос только в том, хотим ли мы изучать правила и делать как они предписывают или мы хотим продолжать работать так как хотим.
Never lose a holy curiosity.
Albert Einstein
P.S.
Уважаемые читатели, кто все же дочитал статью, мне очень интересно Ваше мнение и комментарии, а также рекомендации по аналогичным книгам, таким как книга Майка Кона.
