То и дело на Интернете приходится сталкиваться со спорами противников Методологий Разработки Программного Обеспечения и их сторонников. Сторонники с непревзойденным чувством самооценки (self-esteem) обьяснят вам, что не дело лаптем щи хлебать, и что просто сесть и написать – это «ковбойский» стиль, который ни к чему хорошему не приведет. А надо делать... и дальше, в зависимости от сезона идет название очередной модной методологии разработки программ. Сие излагается с апломбом секретаря парторганизации или там шамана племени, так чтобы сразу было ясно, что любой возражающий идет против линии партии и, того гляди, навлечет на племя проклятие Злых Духов Программного Обеспечения, чтобы и мысли не возникало возражать.
Методология эта обычно изложена в толстых трудах, где подробно описано каждый шаг разработки, включая кто, когда и где решает, что нужно делать, как рассаживаться вокруг музыкальных инструметов, сколько раз прыгать вокруг племенного костра на правой ноге, а сколько на левой, и в какой руке при этом держать бубен. Методология подтверждается многочисленными примерами внедрения (case studies), когда, несмотря на применение методологии, та или иная команда все-таки выполнила запланированный проект почти в срок и почти в рамках бюджета. А каждый возражающий узнает, что он мордой не вышел программы писать, и пошел бы он пасти коз, а не совался бы со свиным рылом в калашный... пардон, программный ряд. В общем, как если бы кто пришел на тусовку, посвященную одежде и моде, в модели прошлого сезона, или, о ужас, ваще в одежке простых смертных.
Для начала, позвольте все-таки сунуться в калашный ряд, поскольку критика оных методологий обычно либо отстутсвует («Не тронь ..., вонять не будет.»), либо звучит достаточно примитивно («Они не работают!»). Две крупнейшие технические проблемы с методологиями разработки ПО, которые я вижу, это избыточность и некорректность примеров внедрения. Две крупнейшие организационные проблемы с методологиями разработки ПО, на мой взгляд состоят в политизированности и вирусной природе, которые делают их идеальным оружием в руках корпоративных паразитов против тех, кто делает реальную работу в проектах. Позвольте пояснить.
Избыточность и некорректность примеров внедрения.
Попробуйте покритикуйте любую методику разработки софта, и тут же раздастся хор голосов: «А мы ее использовали и у нас получалось!» Ну, да, получалось. А копните, и окажется, что использовали-то не по букве инструкций, а в вольной форме. Там на правой ноге прыгнули лишний раз, тут бубен не в той руке держали. Что и отражает причины, почему получается. Если подумать, то любая методика разработки софта сводится обычно к одной-двум фразам. Водопад = «сначала выясни что нужно, потом подумай как это сделать, и только потом пиши код.» Экстремистское программирование = «каждый кусок кода должны быть способны починить хотя бы два члена компанды.» Скрам = «собирайтесь на ежедневные летучки.» И правда, чего такого неверного в том, чтобы подумать прежде чем писать или в летучках, чтобы знать, если кто застрял? Все верно.
При этом, если обратите внимание, все методологии устроены примерно так:
1. N страниц текста, описывающих пляски с бубном.
2. «Программист пишет код»
3. Еще K страниц текста, описывающих пляски с бубном.
То есть по сути любая методология в конце концов сводится к тому, что куча народу – менеджер, менджер проекта или ПМ, лиды тестовой команды, архитектор, специально назначенные «умные товарищи» пляшут с бубном вокруг программиста, который во всем этом гвалте должен в определенный момент написать работающий код, а в остальное время также участвовать в плясках. И возникает законный вопрос, а так ли действительно важно загнуть мизинец правой руки после третьего прыжка на левой ноге и четвертого встряхивания бубна?
Вообще, тема такая, что поневоле хочется отвлечься и написать по ней побольше. Например, вы задумывались, что методологии действительно очень напоминают первобытную охотничью магию? У вас есть заклинания шамана (на основе священных книг, описывающих методологию), наскальная живопись с поверженной добычей (UML диграммы и спецификации), сама технология танца (15 минут, все стоят, каждый имеет минуту на статус), собственный словарь («цыпленок», «свинья»,...), строгая иерархия, определяющая в каком порадке воины-охотники поражают нарисованную на стене пещеры добычу... Вообще, а не в человеческой ли природе устраивать что-то подобоное каждый раз, когда очень хочется и не получается. Ну, скажем, хочется кушать, а мамонт убежал. Или там, программный продукт не работает... Впрочем, я отвлекся.
Вот это я и имею в виду под избыточностью. Одна фраза разбавляется до толстого тома очень относительно относящимися к делу деталями, вокруг которых и разгораются потом страсти и борьба за престол очередной крошечной империи.
Вирусная природа и корпоративные паразиты
Второй пример с этим всем мимукраппом в организационных последствиях. Попросту говоря, они являются плодородной почвой для откровенных и не очень откровенных паразитов, который «участием» в процессе подменяют производство результатов. Поскольку почти каждая такая методология вынужденно включает уйму не имеющих реального значения деталей, то всякое ее применение открывает уйму возможностей оную методологию «улучшить».
Скажем, делать летучки в Скраме не 15 минут, а 20, или там 17. Предлагающий может это подать как значительное улучшение, помогающее команде достичь целей. А если кто захочет возражать, то то же самое может быть выставлено как ухудшение методологии. Кто выиграет? А это уже будет решаться исключительно политикой и влиянием в команде, поскольку реально эти плюс-минус две минуты все равно никакого значения не имеют и никогда не соблюдаются.
Впрочем еще более распространенный вариант – это когда на предложение 17 минут кто-нибудь начинает возмущаться, что вообще весь этот «скрам» - сплошная потеря времени. Вот тут-то можно всласть поплясать на костях «неверного язычника».
Вы можете спросить, а зачем? И вообще, а менеджер, что ли, сам не видит? Менеджер может и видит, более того, может и сам считает, что эти лишние две минуты – ерунда. Но вот то, что вы настояли на своем, поплясали на костях, и команда сделала как вы хотели, показывает, что вы – «лидер», что за вами следуют. А вот это уже плюс без дураков на любом ревью. По крайней мере, если вы этого не сделали, то вам уж точно припомнят, что у вас не такое уж сильное влияние в команде, а надо бы...
В результате протест против любого идиотизма в рамках подобного мимукраппа превращается из логического разговора в эмоционально-политическую игру «свой-чужой». То есть, мы имеем дело с мемовирусом – набором мемов с якорем и носителем. Якорь «свой-чужой» заставляет членов команды принять мемовирус и подчиниться ему, поскольку мимукрапп обычно запускает менеджер, а уж к нему, ясное дело, нужно быть «своим». А потом каждый его носитель начинает его распространять на других как средство расширения своего «влияния» в команде.
К слову, мемовирус – это связный набор мемов с якорем и носителем. Якорь – это мемы из этго набора, заставляющие принять весь комплекс. Носитель – это мемы, засталяющие его распространять дальше. Все остальное – «payload», нагрузка. Если нет якоря или носителя, то нет и мемовируса, а есть просто набор мемов. Скажем, таблица умножения или алфавит – это просто набор мемов, нуждающийся во внешних причинах, чтобы их запомнить или передавать другим. Причины запоминать или распространять в них не встроены. И именно поэтому их так трудно запоминать. Я бы не стал этого обьяснять, но судя по комментариям к предыдущим постам, не все это знают.
Ну, а уж когда команда захвачена таким мемовирусом, то включается самооправдание и рационализация, а народ начинает гордо сообщать всем, что «мы эту методику используем и получается!» Что является уже вторичным носителем, распространяющим мимукрапп вне пределов команды.
С другой стороны...
Собственно, надо признать, что менеджер вводит мимукрапп не от хорошей жизни. Ему-то ведь надо и проект в срок сдать и начальство успокаивать, что все по плану, и какой-то механизм заметания под ковер того, что не лезет. И все эти методологии в этом помогают, по крайней мере с двумя последними пунктами.
Скажем в «водопаде» всегда можно отложить фичу, которую не успеваешь, или даже баг в следующую версию. Конечно, будет мотание хвостом и шевеление ушами, которое надо истолковать ((с) «Повесть о Ходже Насреддине» Соловьева), тем не менее это дает процесс не сделать что-то запланированное с самого начала и все-таки отчитаться о победе. В «скраме» - это перенос на следующий «спринт». В XP я даже не уверен что, но тоже должна быть такая возможность. А уж как хорошо начальству все это докладывать. Одни burndown charts в скраме чего стоят. Красиво. Наглядно. Понятно. И понятно, что все что не лезет заметается под ковер (см. выше как), но зато план по валу, вал по плану. А как еще?
То есть, мимукрапп по сути не является проблемой сам по себе, это лишь симптом другой, более серьезной проблемы. Как я уже писал не раз, мы живем во время смены общественно-экономической формации. Индустриальный социализм по обе стороны океана успешно справлялся с индустриальными рабочими при помощи иерархического менеджмента. С начала 60-х производительные силы и их технологический уровень переросли рамки, в которых иерархический менеджмент эффективен, приводя к сбоям. С «работниками знания» уже невозможно обращаться как с рабочими, это просто не работает. Стандартной реакцией иерархического менеджмента в таких случаях является «научный менеджмент» Тейлора, который по сути сводится к разбиению сложных операций на простые шаги и использованию более дешевой рабочей силы тупо повторяющей эти записанные шаги. В начале двадцатого века именно так были разрушены профсоюзы арсенальных рабочих и производителей оптики, а потом тот же метод успешно применялся много раз. Отсюда и прут все эти методологии.
Проблема только в том, что если проанализировать и разбить на шаги производство первой версии, скажем, игрушки «Минера», то потом сколько ни повторяй эти шаги, а все что будет получаться – это все та же первая версия игрушки «Минера». Чтобы сделать Word или PowerPoint шаги должны быть другими. Но соблазн для иерархического менеджмента все равно слишком велик, а понимания все равно слишком мало. Вот и накатываются на нас волны мимукраппа за мимукраппом. И будет это продолжаться пока будут продолжаться попытки управлять работниками знания при помощи иерархического менеджмента.
В общем-то даже и понятно, что придет на замену. Иерархический менеджмент в работниками знания не работает, а вот сетевой, вроде того, что делается в Гугле или сеть PM’ов на Майкрософте – работает.
А напоследок я скажу...
... что вся эта моя критика вовсе не отменяет того здравого, что есть в этих методиках.
Я вообще-то с этого начал, но некоторые люди удивительно тупы, игнорируют прямой текст, а потом начинают топать ногами и кричать, что «они делали и у них получалось», и вообще, не лез бы ты, Элдар, в калашный ряд... Так вот, я полностью одобряю идею подумать, прежде чем писать код; знать, что требуется, перед тем как делать дизайн; собираться на летучки, чтобы вся команда была в курсе кто что делает и нет ли у кого проблем; иметь более одного члена команды, способного исправить конкретный кусок кода и так далее. Я даже понимаю ценность процесса как такового, когда иногда не важно, прыгнуть на левой ноге или на правой, но надо чтобы все прыгнули на одной и той же ноге.
К слову, как обычно с персонального блога...
Я просто указываю на проблемы, которые применение подобных методик нередко создает. И да, я их преувеличил, для внятности. До серьезных проблем они дорастают только в очень больных организациях, в которых мне, слава Богу, уже давно не приходилось работать. Тем не менее, я считаю, что об этих проблемах надо знать, о них надо думать, и если вы – менеджер, то следить, чтобы они не выросли до серьезного масштаба и не влияли на ваши решения. Поскольку обидно терять из-за них хороших людей, и опасно продвигать из-за них плохих. И важно также понимать, что это не панацея для лечения когнитивного диссонанса у высшего менеджмента, а лишь способ ограничить его негативные последствия для вас. А в остальном... ну, мимукрапп. Ну и что? Ничего страшного. В конце концов, почему бы и не поплясать чуть вокруг костра?
No comments:
Post a Comment