Agile-менеджмент. Лидерство и управление командами

Методологии, конкурирующие с Agile

Редко когда попадаются игры, не предусматривающие конкуренцию между игроками, и лишь немногие системы обходятся без конфликта. Без расхождения во взглядах между разными людьми жить было бы не так интересно. К счастью, в мире гибких технологий предостаточно здоровой конкуренции, например между Scrum и Экстремальным программированием, Scrum и канбаном и даже между Scrum и Scrum!^[5] Но гибкие методы разработки не будут здесь единственными игроками. Существует несколько сильных и многообещающих конкурирующих подходов, в основе которых лежат идеи, аналогичные идеям Agile-методологий, дополняющие их, а часто и входящие с ними в прямое противоречие.

Одними из самых крупных конкурентов будут методологии бережливой разработки программного обеспечения (Lean software development), переносящие идеи бережливого производства в область разработки ПО. Семь принципов бережливого производства [Poppendieck 2009: 193] основываются на четырнадцати принципах Дао Toyota (философии управления компании Toyota) и четырнадцати принципах менеджмента Э. Деминга. Между Agile- и Lean-методологиями много общего, поэтому часто они играют на одной стороне, ими занимаются одни и те же эксперты, у них одни и те же фанаты, а их развитие освещается в одних и тех же блогах, журналах и ТВ-шоу. С управленческой точки зрения Lean-методологии – с их акцентом на сокращении непродуктивных затрат и оптимизации систем в целом – внесли большой вклад в развитие гибких методологий. Хотя бережливые методологии разработки ПО возникли на несколько лет позднее Agile, они сравнялись с ними по числу консультантов, коучей, профессиональных консорциумов^[6] и проводимых конференций.

Менее крупным, но весьма способным игроком будет также движение за мастерство программирования, основополагающим документом которого стал манифест в защиту мастерства программирования (рис. 2.3), о котором говорят, что он одновременно расширяет Agile-манифест и бросает ему вызов. Сторонники этого движения считают, что разработчики ПО вовсе не инженеры, а мастера. (Некоторые полагают вполне уместным сравнение с распространенной в Средневековье моделью мастеров и подмастерьев.) В общем, это движение – шустрый и бесстрашный новый игрок, возникший рядом с бережливыми и гибкими методологиями и имеющий свои собственные конференции, книги и форумы (хотя и не в таком количестве). Эти три «легкие» методологии вместе стали отличной командой, несмотря на периодически возникающие между ними бурные споры.

Но и тяжеловесы все это время тоже не стояли на месте. Возможно, наиболее известным (и наиболее спорным) из них будет методология CMMI (Capability Maturity Model Integration). Ее разработка с 1987 года ведется Институтом программной инженерии, исследовательским центром на базе Университета Карнеги – Меллон. Проект начался с создания протокола оптимизации процессов разработки ПО, но постепенно трансформировался в более абстрактную модель, которая в настоящее время применяется для оптимизации процессов и в других отраслях. В модели описываются пять уровней зрелости процессов в двадцати двух процессных областях, и она ставит себе целью порождение рекомендаций по их оптимизации. Но данная модель лишь указывает, в каких именно процессных областях возможна оптимизация. Она не дает рекомендаций относительно конкретных ее способов. По этой причине некоторые сторонники Agile полагают, что, несмотря на свой объем (документация, описывающая методологию CMMI, насчитывает многие сотни страниц), она все же совместима с гибкими методологиями, поскольку последние дополняют ее, давая рекомендации, в том числе и по конкретным способам оптимизации процессов. Но, как это всегда бывает среди сторонников гибких технологий, и тут не обходится без споров. Многие считают, что, несмотря на благие намерения, положенные в ее основу, CMMI в силу своей тяжеловесности уводит компании в сторону бюрократии и создания не вполне дееспособных команд, которые весьма впечатляюще выглядят со стороны, но не могут блеснуть реальными результатами.

С такой же смешанной реакцией столкнулась и методология, изложенная в «Руководстве к своду знаний об управлении проектами» (Guide to Project Management Body of Knowledge, PMBOK), издаваемом и поддерживаемом Институтом управления проектами. Интересно, что это руководство первоначально возникло как описание лучших практик в области проектного менеджмента в целом. С момента первого издания в 1987 году оно подверглось нескольким переработкам и стало ближе к идеологии Agile в качестве реакции на успехи, достигнутые проектными менеджерами, практикующими гибкие методологии. В отличие от CMMI, методология, продвигаемая в рамках PMBOK, предлагает проектным менеджерам конкретные рекомендации относительно управления проектами. И хотя рекомендуемые ею практики не всегда хорошо сочетаются с принятыми в гибких методологиях, многие проектные менеджеры предпринимают активные попытки преодолеть имеющиеся расхождения. То же самое можно сказать о PRINCE2 – похожей методологии, издаваемой и поддерживаемой британским министерством государственной торговли. Эта методология используется главным образом в Европе.

Последним важным направлением в этом списке будет унифицированный процесс разработки ПО, наиболее известный в версии унифицированный процесс 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.

К сожалению, проектный менеджмент и функциональный (линейный) менеджмент часто путают. В ряде отличных книг, написанных ведущими экспертами, включая «Гибкий менеджмент» (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 и Экстремальное программирование. Однако ни один из этих методов не рассматривает роль линейного менеджмента (не путать с проектным менеджментом) в компаниях, перешедших на гибкие методологии разработки. В результате линейный менеджмент часто становится препятствием на пути принятия гибких методологий.

Подумать и сделать

Давайте посмотрим, сможете ли вы применить в своей компании некоторые идеи, изложенные в данной главе:

• Взгляните на свою организацию с точки зрения семи проектных измерений (люди, функциональность, качество, инструменты, время, ценность, процесс). Учитываете ли вы все эти измерения в своих проектах по разработке ПО? Гибки ли ваши команды во всех семи измерениях? Если нет, то что вы планируете по этому поводу предпринять?

• Подумайте о менеджерах, работающих в вашей компании. Кто из них может стать потенциальным препятствием на пути внедрения гибких методологий? Можете ли вы что-то в связи с этим предпринять? Удостоверьтесь, что вы четко понимаете, что вам нужно от них, чтобы ваш подход к внедрению Agile-методологий оказался успешным.

• Всем ли ясно, кто является линейным менеджером (и по отношению к кому), а кто нет? Существует ли неясность или разногласия относительно распределения функций между линейными и проектными менеджерами? Если да, то что вы предпримете, чтобы решить эту проблему?

• Развивайте свои навыки в области Agile-методологий, подписавшись на блоги или группы, в которых обсуждается данная тематика. Актуальный список этих блогов и групп можно найти на сайте, посвященном Менеджменту 3.0 (http://www.management30.com).

Глава 3
Теория сложности

Способность задавать вопросы отличает нас от всех остальных форм жизни. Никакой другой биологический вид не задает вопросов о смысле своего существования, сложности Вселенной или сложности самого себя.

Герберт Бойер,

профессор биохимии

Многие эксперты в области гибких методологий согласны, что команда разработчиков представляет собой сложную адаптивную систему, поскольку состоит из множества частей, взаимодействующих друг с другом и отделенных внешней границей, и способна изменяться и учиться на собственном опыте [Highsmith 1999: 8], [Schwaber 2002: 90], [Larman 2004: 34], [Anderson 2004: 1], [Augustine 2005: 24]. Кто я такой, чтобы утверждать обратное?

Журнал «Эмерджентность: Теория сложности в применении к организациям» однажды провел обширное исследование книг по менеджменту, в которых упоминается теория сложных систем. Среди рецензентов были специалисты в самых различных областях, включая физику и математику. Все они сошлись во мнении о полезности теории сложности при управлении организациями и для менеджмента в целом:

Было зафиксировано общее согласие [рецензентов], что использование идей теории сложности имеет значительные перспективы для менеджмента как дисциплины и при практическом управлении организациями^[7].

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

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

Всегда полезно представлять себе контекст и историю вопроса. Когда вы в следующий раз окажетесь на вечеринке, то сможете блеснуть, объяснив, например, разницу между общей теорией систем и теорией динамических систем, а также дав понять, что рецепт восхитительного лимонного торта, которым угощает хозяйка, не сложный (complex), а лишь запутанный (complicated).

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

Важность междисциплинарного подхода

В главе 13 «Как управлять ростом организационных структур» обсуждаются организационные колодцы, то есть разделение сотрудников, выполняющих разную работу, и то, почему это часто оказывает негативное воздействие на результаты деятельности всей компании. Интересно, что подобная ситуация много лет существовала и в науке.

Большинство университетов и исследовательских институтов организованы именно в виде таких колодцев. Физики работают бок о бок с другими физиками, биологи – с биологами, а математики – с математиками. Это привело к фрагментации науки и распространению туннельного зрения среди ученых и исследователей. Различные научные дисциплины настолько изолированы друг от друга, что ученые обычно не знают, над чем работают их коллеги [Waldrop 1992: 61].

Организационные колодцы в науке – это проблема, поскольку многие явления из разных научных областей часто похожи друг на друга. Например, некоторое время назад экономисты не могли понять природу такого явления, как «локальное равновесие», в то время как физикам уже была известна природа его физического аналога [Waldrop 1992: 139]. Фазовые переходы в физике подозрительно напоминают случаи периодически нарушаемого равновесия в эволюционной биологии. Биологи заметили, что математики могут помочь им в анализе экологии видов [Gleick 1987: 59]. А некоторые «открытия» математиков, как выясняется, были за годы до того сделаны метеорологами [Gleick 1987: 31].

В течение многих десятилетий ученые из различных областей пытались понять сложные явления, которые не могли объяснить. Но когда наметились более тесные междисциплинарные связи между различными областями и возникло общее представление о том, что изучаемые разными науками системы – сложные, внезапно многое стало гораздо понятнее. Я где-то читал, что самые значительные прорывы в науке совершались именно тогда, когда ученым приходилось работать в областях, с которыми они прежде не были знакомы. А все потому, что они привносили туда знания и опыт (включая опыт трудностей и неудач) из тех областей, в которых были специалистами!

Как и гибкие методики разработки ПО, теория сложности подразумевает междисциплинарный подход к решению проблем. Мышление в категориях сложных систем – это противоядие от излишней специализации в науке. Оно предполагает существование общих закономерностей в поведении систем, исследуемых различными научными дисциплинами, и продвигает подход к решению проблем, базирующийся на концепциях из различных наук. Однако теория сложности далеко не первая попытка синтеза различных предметных областей. Давайте бросим беглый взгляд на историю вопроса.

Общая теория систем

В конце 1940-х годов усилиями группы ученых и исследователей, возглавляемых Людвигом фон Берталанфи, была создана область науки, получившая название общая теория систем (иногда ее называют просто теория систем). В своих исследованиях эти ученые исходили из представления, что большинство явлений во Вселенной можно рассматривать как сеть взаимодействий между элементами определенной системы. При этом независимо от того, будут ли данные системы биологическими, химическими или социальными по своей природе, их поведению присущи общие закономерности, исследование которых может пролить свет на поведение систем в целом. Основной целью теории систем, таким образом, было создать общий междисциплинарный понятийный аппарат и язык, при помощи которых можно было бы описывать сходные явления во всех областях науки.

Одним из достижений теории систем, развитие которой продолжалось вплоть до 1970-х годов, был перенос фокуса с элементов системы как таковых на организацию этих элементов. Тем самым было признано, что взаимоотношения между элементами системы – динамические, а не статические. Ученые идентифицировали и изучили такие явления, как аутопоэзис (самопостроение или способы, которыми системы конструируют сами себя), идентичность (каким образом системы можно опознать), гомеостаз (способность систем поддерживать свою стабильность) и проницаемость (то, как системы взаимодействуют с окружающей их средой) [Mitchell 2009: 297].

Именно общей теории систем мы обязаны пониманием, что группы разработчиков представляют собой системы, которым свойственна способность к самопостроению, а также к созданию и поддержанию собственной идентичности. Таким группам необходимо взаимодействовать с внешней средой, а взаимодействия между членами группы столь же важны, сколь и характеристики отдельных членов группы (или даже важнее).

К сожалению, объединение этих первоначально разрозненных концепций не было доведено до конца (что не должно удивлять тех разработчиков ПО, которые пытались соединить различные практики или технологии). И тем не менее наследие общей теории систем весьма значительно. Почти все законы этой теории применимы и к сложным системам [Richardson 2004a: 75], и в целом эта теория продвинулась дальше, чем попытки унифицирования в области разработки программных продуктов.