Препятствие на пути Agile-методологий
Эмпирические данные вновь и вновь подтверждают, что Agile-методологии, если правильно ими пользоваться, обеспечивают огромный возврат инвестиций [Rico 2009]. Но если эти методологии дают столь блестящие результаты, то почему далеко не все ими пользуются? И почему столько проектов по разработке ПО во всем мире все еще заканчиваются неудачами?
В опросе, посвященном оценке текущего состояния Agile-методологий, проведенном в 2009 году компанией VersionOne, респонденты в качестве причин, препятствующих принятию компаниями гибких методологий, указали следующие: «менеджмент настроен против изменений», «опасение утратить управленческий контроль», «недостаточная техническая дисциплина», «команды настроены против изменений» и «недостаточный уровень компетентности разработчиков». Параллельно упоминается потребность организаций в планировании, предсказуемости и документировании своих действий [VersionOne 2009].
Подождите… Давайте еще раз вглядимся в эти причины: тут говорится об управленческом контроле, управлении организационными изменениями, выращивании талантов…
Простите, возможно, я не прав, но… разве все это не прямые функции менеджмента? Не значит ли это, что именно менеджеры по всему миру будут основным препятствием на пути внедрения Agile-методологий?
Как менеджера меня расстраивает этот вывод.
А как автора – радует.
Я думаю, что гибкие методологии упустили из поля зрения важность линейного менеджмента. Если менеджеры не знают, чем им заниматься и чего ожидать от внедрения гибких методологий в своих организациях, то почему они должны поддерживать переход к этим методологиям? В чем состоит послание Agile-методологий этим менеджерам? В том, что «менеджеры нам не нужны»? Тогда неудивительно, что внедрение этих методологий наталкивается на препятствия во всем мире.
Чтобы организации могли воспользоваться всеми преимуществами гибких методологий, они должны ответить на важный вопрос: какое будущее ожидает менеджеров в мире Agile?
Линейный и проектный менеджмент
Мое имя в Голландии не самое распространенное. Поэтому на разных этапах моей карьеры мне приходилось мириться с тем, что его часто коверкали. Временами из-за этого возникали недоразумения. Когда имена людей или названия предметов похожи, многие склонны почти не замечать остальных различий между ними. Если бы имя Эллы Фицджералд было не Элла, а Юрген, то, уверен, коллеги попросили бы меня спеть.
Мне кажется, что с термином «менеджер» есть точно такая же проблема.
В 2005 году группа людей, специализирующихся в области управления (проектные менеджеры, линейные менеджеры и др.) собрались вместе и опубликовали Декларацию взаимозависимости (рис. 2.4).
В первом воплощении декларация в первую очередь предназначалась проектным менеджерам. Позднее стало ясно, что ее принципы могут быть интерпретированы более широко и применены к «менеджменту в целом». И все же в первую очередь декларация ориентирована на управление проектами по разработке ПО, а не на управление группами людей. Это необходимо подчеркнуть, поскольку именно авторы декларации впоследствии основали организацию Agile Project Leadership Network.
К сожалению, проектный менеджмент и функциональный (линейный) менеджмент часто путают. В ряде отличных книг, написанных ведущими экспертами, включая «Гибкий менеджмент» (Agile Management) [Anderson 2004], «Управление Agile-проектами» (Managing Agile Projects) [Augustine 2005] и «Гибкое управление проектами» (Agile Project Management) [Highsmith 2009], вопросы проектного и функционального менеджмента обсуждаются параллельно. Та же ситуация наблюдается и на многих форумах, в блогах и журналах. Мне бы хотелось, чтобы это было не так, поскольку проектный и линейный менеджмент – не одно и то же. Это все равно что путать разработчиков ПО с системными администраторами. Возможно, они разделяют одни и те же идеи, смеются над одними и теми же шутками и (фигурально выражаясь) стригутся и одеваются одинаково, но все же это разные люди. (Я серьезно. Попробуйте попросить разработчика софта починить вам компьютер. Но лучше даже не пробуйте.)
Не делая четкого разграничения между линейными менеджерами и менеджерами проектов, мы затрудняем понимание и теми и другими своей роли в компаниях, практикующих гибкие методологии разработки. К счастью, я далеко не единственный, кто это понимает. В нескольких книгах, вышедших задолго до моей, включая «За закрытыми дверями» (Behind Closed Doors) [Rothman, Derby 2005] и «Управление разработкой ПО на основе Lean-методологий» (Leading Lean Software Development) [Poppendieck 2009], функции линейных менеджеров в компаниях, специализирующихся на разработке ПО, изложены более четко.
В своей книге я последовательно провожу различие между линейным и проектным менеджментом. Моя основная цель – помочь линейным менеджерам (включая тех, кто руководит командами разработчиков, и лидеров команд) понять, в чем состоит их роль в компании. Но я уверен, что и проектные менеджеры, системные менеджеры, сервис-менеджеры, офис-менеджеры и кофе-менеджеры тоже найдут для себя в этой книге некоторые интересные моменты.
А что касается тех, кто думал, открывая эту книгу, что я DJ Юрген, то им не повезло.
Резюме
Гибкие или Agile-методологии – это подход к разработке программного обеспечения, появившийся в 1990-е годы в качестве реакции на засилье бюрократии, а также частных методов, создаваемых каждый раз заново «под конкретную задачу» (все они не обеспечивали успешной разработки ПО).
Гибкие методологии, принципы и ценности которых изложены в Agile-манифесте, фокусируются на людях и командах, частых и высококачественных релизах программных продуктов, тесном сотрудничестве с заказчиками и быстрой реакции на возникающие изменения при минимуме предварительного планирования.
Ценности и принципы гибких подходов реализуются при помощи различных методов, таких как Scrum и Экстремальное программирование. Однако ни один из этих методов не рассматривает роль линейного менеджмента (не путать с проектным менеджментом) в компаниях, перешедших на гибкие методологии разработки. В результате линейный менеджмент часто становится препятствием на пути принятия гибких методологий.
Подумать и сделать
Давайте посмотрим, сможете ли вы применить в своей компании некоторые идеи, изложенные в данной главе:
• Взгляните на свою организацию с точки зрения семи проектных измерений (люди, функциональность, качество, инструменты, время, ценность, процесс). Учитываете ли вы все эти измерения в своих проектах по разработке ПО? Гибки ли ваши команды во всех семи измерениях? Если нет, то что вы планируете по этому поводу предпринять?
