Последним важным направлением в этом списке будет унифицированный процессразработки ПО, наиболее известный в версии унифицированный процесс Rational (Rational Unified Process, RUP). Он был разработан в 1997 году компанией Rational Software (сейчас принадлежит IBM). Для разработчиков ПО процесс RUP будет тем же, чем для проектных менеджеров стали методологии, изложенные в руководстве PMBOK. В нем содержится описание стандартизированных методов проектного управления, которые могут (и должны) адаптироваться к конкретным проектам; однако документация составлена таким образом, что весь подход зачастую воспринимается как бюрократический. Сторонники гибких методологий считают, что процесс разработки формируется в ходе проекта, начинаясь с минимального числа практик. В рамках RUP продвигается противоположный подход, в котором изначально предписывается большое количество практик с сопровождающей их рекомендацией, что в ходе проекта от ненужных практик можно отказаться. (Я часто сравниваю этот подход с покупкой Boeing 747, который владелец затем разбирает на части, чтобы собрать велосипед для поездок за покупками.) Неудивительно, что на фоне многочисленных успехов Agile-методологий этот подход подвергся нескольким ревизиям с целью сделать его более гибким, в результате чего возникли такие его модификации, как гибкий унифицированный процесс (Agile Unified Process, AUP), открытый унифицированный процесс (OpenUP)и минимально необходимый гибкий процесс (Essential Agile Process, EssUp). Но ни один из них не нашел широкого применения, сравнимого с распространением Agile-методологий.
Препятствие на пути Agile-методологий
Эмпирические данные вновь и вновь подтверждают, что Agile-методологии, если правильно ими пользоваться, обеспечивают огромный возврат инвестиций [Rico 2009]. Но если эти методологии дают столь блестящие результаты, то почему далеко не все ими пользуются? И почему столько проектов по разработке ПО во всем мире все еще заканчиваются неудачами?
В опросе, посвященном оценке текущего состояния Agile-методологий, проведенном в 2009 году компанией VersionOne, респонденты в качестве причин, препятствующих принятию компаниями гибких методологий, указали следующие: «менеджмент настроен против изменений», «опасение утратить управленческий контроль», «недостаточная техническая дисциплина», «команды настроены против изменений» и «недостаточный уровень компетентности разработчиков». Параллельно упоминается потребность организаций в планировании, предсказуемости и документировании своих действий [VersionOne 2009].
Подождите… Давайте еще раз вглядимся в эти причины: тут говорится об управленческом контроле, управлении организационными изменениями, выращивании талантов…
Простите, возможно, я не прав, но… разве все это не прямые функции менеджмента ? Не значит ли это, что именно менеджеры по всему миру будут основным препятствием на пути внедрения Agile-методологий?
Как менеджера меня расстраивает этот вывод.
А как автора – радует.
Я думаю, что гибкие методологии упустили из поля зрения важность линейного менеджмента. Если менеджеры не знают, чем им заниматься и чего ожидать от внедрения гибких методологий в своих организациях, то почему они должны поддерживать переход к этим методологиям? В чем состоит послание Agile-методологий этим менеджерам? В том, что «менеджеры нам не нужны»? Тогда неудивительно, что внедрение этих методологий наталкивается на препятствия во всем мире.
Чтобы организации могли воспользоваться всеми преимуществами гибких методологий, они должны ответить на важный вопрос: какое будущее ожидает менеджеров в мире Agile?
Линейный и проектный менеджмент
Мое имя в Голландии не самое распространенное. Поэтому на разных этапах моей карьеры мне приходилось мириться с тем, что его часто коверкали. Временами из-за этого возникали недоразумения. Когда имена людей или названия предметов похожи, многие склонны почти не замечать остальных различий между ними. Если бы имя Эллы Фицджералд было не Элла, а Юрген, то, уверен, коллеги попросили бы меня спеть.
Мне кажется, что с термином «менеджер» есть точно такая же проблема.
В 2005 году группа людей, специализирующихся в области управления (проектные менеджеры, линейные менеджеры и др.) собрались вместе и опубликовали Декларацию взаимозависимости(рис. 2.4).
В первом воплощении декларация в первую очередь предназначалась проектным менеджерам. Позднее стало ясно, что ее принципы могут быть интерпретированы более широко и применены к «менеджменту в целом». И все же в первую очередь декларация ориентирована на управление проектами по разработке ПО , а не на управление группами людей . Это необходимо подчеркнуть, поскольку именно авторы декларации впоследствии основали организацию Agile Project Leadership Network.
Читать дальше
Конец ознакомительного отрывка
Купить книгу