Шло время, люди смотрят - видят чувака колбасит не по детски, некоторым тоже захотелось поколбасится - у монаха появились ученики. Сидят значит, втыкают на яблони, храм забацали в свободное от просмотра деревьев время. И не то чтобы еще кто-то в момент падения фруктов достиг аналогичных результатов, если бы это работало именно так - то все крестьяне давно подключились бы к космосу и хана народному хозяйству. Но некоторых, особо усердных, все же штырило: кого-то от ручейка из которого брали воду для поливки сада, кого-то от шмеля пролетающего на бреющем полете мимо коровы поедающей сено в день летнего солнцестояния, кого-то просто так, за компанию. И с строго научной точки зрения не понятно какова роль яблок в процессе: эксперимент по типу того который делают из года в год на центральных телеканалах с жителями Виларибы и Вилабаджо тут не поставишь, но, поскольку яблоки в процессе присутствуют, да и народу надо чем-то заняться до просветления - будем считать что яблоки работают, хай втыкают на яблоки.
Собственно, почему я вспомнил эту историю, которой возможно никогда не было. Это известная штука в мире, назовем это так, “духовных практик”: одного проколбасило, остальные тусуются рядом, вдруг тоже поколбасит. Религии так не возникают, но что-то попроще - вполне. Когда в интернете кто-то неправ и заходит речь про Agile и с Agile’ом связанные штуки, вплоть до того же TDD, иногда возникает ощущение что спор идет между какими-то сектантами и атеистами. Начиная от истории возникновения, и заканчивая банальной лингвистикой: говорят о Agile-практиках, и опыте, как о некоторой сакральной сущности: аналогия про монаха с яблоком напрашивается сама собой.
Не то чтобы это было чем-то плохим, просто накладывает определенные требования к восприятию данного вопроса. То есть, в идеале, для того чтобы понять о чем говорят эти люди и почему им это нравится, хорошо бы прочувствовать это на собственной шкуре под руководством опытного наставника: по крайней мере того кто способен отличить - просветление это, или на голодный желудок съел забродившее яблоко, через час пройдет. Если же ощутить на собственной шкуре не получается, по крайней мере не стоит читать об этом в советских газетах, транслируя на собственные серые будни, а то получится что коварные капиталисты придумали очередной способ для угнетения рабочего класса, которому, по традиции и так не очень.
В IT, равно как и в любом другом производстве, присутствует великое множество людей, которые так или иначе задействованы в получении конечного результата. Даже в рамках идеализированной модели, все эти люди, вернее группы людей, имеют разные цели и разный инструментарий для их достижения. Например, разработчики хотели бы иметь "чистый", поддерживаемый код, продажники - много клиентов хороших и разных, глава компании - довольных акционеров, и так далее и тому подобное. В конечном счете все эти "идеальные" цели в принципе описывают нормальный, хорошо продаваемые продукт, которым довольны потребители, но описывают с разных точек зрения. Но все мы люди, поэтому есть еще цели и более другие: как разработчик, я вполне могу хотеть иметь актуальный для рынка рабочей силы набор знаний и умений. Причем от "неплохо бы иметь современные инструменты и писать на продаваемом языке программирования", до "мое дело генерировать код, а не разбираться с устройством синхрофазатрона(потому как умение генерировать код я продать могу, а синхрофазатрона есть только тут)".
Обычно, когда речь заходит о том что в принципе у людей могут быть какие-то свои цели и свой набор тараканов в голове, некоторые товарищи инстинктивно тянутся к томагавкам и более крупнокалиберным штукам. Мол платят тебе, тварь, не за то чтобы ты игрался в новые блестящие кубики, а за то чтобы копал от забора до обеда, пардон, решал проблемы заказчика. С этой мыслью вот какая штука получается: она вполне логична(что не исключает наличие целиком логичных контраргументов), но по-сути своей не особо конструктивна. Дискуссию можно развести на 100500 страниц, но каждый останется при своем мнении, только еще и переругаемся.
Проблема в том что вот есть я, допустим программист, допустим желающий играться в более продвинутые кубики, в то время как платят мне за старые и облезлые. Но постойте, платят мне, за то, что применив логику и прочую соображалку я из этих старых и облезлых кубиков делал что-то полезное, то есть по-сути платят и за то что я, по крайней мере время от времени думаю, и за результаты этого думания. И если в результате думания, кроме "полезного" выхлопа, появляются и такие вот неконструктивные мысли, с этим надо считаться: равно как большинство из нас не способно работать по графику: пришел в восемь утра, включил мозг, что-то делал, в шесть вечера встал, выключил мозг, пошел домой, так и выкинуть часть мыслей, без существенного вреда для оставшихся - тоже несколько проблематично.
Так вот: если вам сначала говорят о том что "кто платит, тот и танцует", а твоя задача копать и не задавать лишних вопросов, а потом начинают вещать про SCRUM и его прелести: это повод напрячься. Потому что SCRUM и прочий Agile мягко обходят этот вопрос стороной, более того позиция "раб должен работать и не выпендриваться" может быть крайне деструктивной для всего этого дела.
Философия SCRUM'а, де-факто базируется как раз на том, что в процессе взаимодействуют разные люди, с разными целями и задачами, и взаимодействие это, с одной стороны движет к поставленным целям, с другой - позволяет осуществлять относительно ненапряжный обмен тараканами. Ключевыми элементами этой игры являются собственно не события(типа SCRUM-митингов) и не артефакты, а роли, вернее даже не столько роли, сколько система коммуникаций между ними. То самое:
"Individuals and interactions over processes and tools"
По-сути роли и коммуникации между персонажами играющими конкретные роли и является той самой системой
"сдержек и противовесов", которая или позволяет механизму эффективно работать, или превращает процесс в лютый трэш и угар. Ритуалы и порождаемые ими артефакты носят скорее вспомогательный характер, и скорее иллюстрируют как соответствующая коммуникация и её результат могут быть получены.
Например, известный ритуал по оценке историй, scrum poker, и всьо такое. Product owner рассказывает "а че делать нада", команда задает вопросы, потом команда посредством полутайного голосования пытается оценить сложность. Обсуждают чего ждать, насколько все сложно, можно ли разделить проблему на более мелкие, потом ставят оценки сложности и опять обсуждают. Главных целей этого общения две: команда должна узнать от первоисточника все что требуется, а так же должна выставить свою оценку сложности. В качестве бонуса product owner может проникнуться сложностью исполнения его хотелок. В принципе все круто, но есть одно но.
Допустим product owner - где-то там, чистокровный буржуй, работает на компанию с десяток лет и вообще очень уважаемый в глазах своих друзей и коллег человек, возможно даже искренне преданный делу. А команда где-то тут, обычные аутсорс-рабы, работают на буржуев через третьи руки, по статусу в parent company - где-то между обслуживающим персоналом и локальными Junior'ами. То есть проговорить что-то типа "нам тут предлагают немного поредактировать творчество неизвестного индусского брата, который писал эту хрень укуренный в жопу, левой пяткой правой руки, представляя себя как минимум Шивой" - нельзя вопщем такое говорить. Если вы сидите в одной комнате, и вообще по социальному статусу примерно такой же буржуй как и ваш product owner, - ради бога, поржете вместе. Если вы раб из страны третьего мира, лучше положить трубку, обсудить индусское народное творчество в узком командном кругу, а всем желающим выдать результат в виде story points. Цели коммуникации вроде как соблюдены, и никто не оскорблен в лучших чувствах.
Ситуация казалось бы простая и прозрачная, что может пойти не так? Допустим, посовещавшись и поговорив о странной психиатрической подоплеке, подвигшей автора некого куска кода выразить свои мысли именно так как это было сделано, команда, на с виду простой таск поставила слишком много story points. Product owner, с удивлением пишет мол "чуваки, че так много?". Переводя с языка матерного на язык дипломатический команда может ответить мол "сами мы не местные, этот код видели полтора раза, и он показался нам несколько сложным, поэтому предвидим сложности в имплементации и тестировании вышеозначенных хотелок" - "а, ну ок" - ответит product owner, возможно предварительно сбегав к местной братве, которая ему расскажет про индусов, грибы и почему их не стоит смешивать.
И все было бы хорошо, но эту шаткую конструкцию легко порушить. Достаточно заиметь еще одного персонажа в этой истории, которого как бы в SCRUM-процессе нет, а по факту вот он тут бегает: скажем менеджер, который приглядывает за парой тройкой местных аутсорс команд. Может прочитать письмо от product owner'а и подумать, а, ну ок, чуваки разберуться не в первый раз, возможно перед этим спросив у кого-нить "чо за фигня", а может... КЛИЕНТ НЕДОВОЛЕН, АХТУНГ, СВИСТАТЬ ВСЕХ НАВЕРХ! Обнаглевшей команде "вставляют и проворачивают", с определенным уровнем жестокости, а product owner'у сообщают что мол да, произошла накладка, больше такого не повторится, а чтобы как-то загладить нашу вину, мы тебе запилим эту фичу в кратчайшие сроки, буквально до завтра все сделаем. Видя такой аттракцион невиданной щедрости(было не к спеху, спринт-другой терпело, но завтра так завтра), product owner, как человек воспитанный говорит "спасиба чуваки, я в вас верю!", и записывает себе в черный блокнотик "если свербит левая пятка, можно просить почесать". Таски на команду начинают сваливаться в обход процесса чаще и чаще, команда звереет, а SCRUM... а что SCRUM, SCRUM закончился пару предложений назад.
Или вот, ежедневная пятиминутка ненависти: daily stand-up. На самом деле ничего страшного: поскольку в этой игре ответственность за результат общекомандная, а не индивидуальная, то поговорить пару минут на тему "шо у нас как" - вполне себе светлая мысль. Хотя бы для того чтобы понять мы вообще успеваем закончить то что обещали вовремя, или нет. А может кому помощь нужна, а может перегруппироваться нужно. Как отдельный ритуал, daily stand-up, очень полезен в случае с вновь созданными командами или для команд которые в принципе мало общаются внутри в течении дня. Тогда принуждение к разговору очень даже нужно. В остальном: если команда знает что такое daily stand-ups, и что от них нужно команде, то эти самые daily stand-ups имеют привычку появляться тогда когда они нужны и исчезают когда можно и без них. Часть магии хорошо сработавшейся команды.
Итак, собирается команда, и немного обсуждает "где мы есть и где мы будем есть". Полезность этого ритуала можно убить разными способами, самый простой: так или иначе свести все исключительно к формальному ответу на три сакральных вопроса. Формальный ответ выглядит так: "Вчера я работал над тикетом за нумером 113245, сегодня планирую заниматься тем же, пока никаких проблем нет". Если 113245 - это не история с душком, то номер никому ничего не скажет о том что на самом деле происходит, равно как не будет особо понятно - два/три/пять дней работы - это вообще ожидаемо, или надо начинать волноваться потому что можем не закончить? Формальные ответы на сакральные вопросы в принципе такой информации не дают, и тут или появляются дополнительные вопросы, или действо теряет практический смысл для команды и проводится с целью "шобы було". Усугубить ситуацию может присутствие на действе дополнительных персонажей, которые ограничивают то что может быть сказано. В особо веселых случаях, которые воспринимают происходящее как ежедневный отчет по проделанной работе. В таких случаях иногда появляются даже два, три или четыре стэндапа. Один - внутри команды, один - для команды и какого-нить локального менеджера, один для команды, локального менеджера и сочувствующих на том конце мира, и последний для всех желающих. SCRUM'ом это перестает быть в тот момент, когда на daily stand-up'е вы не можете сказать: "я смотрю на 113245(будь проклят тот день когда из укропа и петрушки решили готовить наркотики!), и этот адский писец вгоняет меня в депрессию, вчера лечился от депрессии мультиками, сегодня попробую еще раз сделать с этим шо-нить разумное".
Истории можно продолжать генерировать долго, но суть в принципе понятна. Как в шахматах, эта хрупкая конструкция держится на правилах по которым ходят фигуры. На основе правил можно разыгрывать какие-то стандартные комбинации, можно включать фантазию. Но, если в шахматы, добавить например необходимость добавлять или удалять случайную фигуру с доски каждые три хода - это будет уже другая игра, может быть интересная, а может и не очень. А если на доску сядет голубь, и просто разнесет к чертям результаты трехчасового пыхтения над диспозициями, все эти причудливые защиты и атаки, то будет как-то неприятно и возможно даже мучительно больно за бездарно потерянное время. Садиться играть стоит по крайней мере представляя себе правила игры и имея ненулевые шансы выиграть.
(Все персонажи и события являются плодом больного воображения автора, любое совпадение с реальностью - случайно. Во время написания ни один яблоневый куст с укропом не пострадал)
Сообщения
Комментариев нет:
Отправить комментарий