А я там выше как раз привёл пример. Элемент поведения -- это не одно действие, а определенный аспект того, что класс делает. Это может быть далеко не одно действие. Более того, в стратегии и объекты внутри могут быть (тот же объект синхронизации в приведенном ранее пример подсчёта ссылок). Для того, чтобы считать что-то стратегией важно то, что оно делает, а не то, как реализовано. Это уже детали конкретной стратегии.
Функция, естественно, может описывать поведение. Но, скажем, упомянутое выше "как синхронизировать доступ к счетчику ссылок" -- это вполне себе аспект поведения объекта. Хотя там -- минимум два метода, стратегия описывается классом, а в экземпляре класса ещё и объект синхронизации (под виндой, скажем, критическая секция) запрятан.
Вообще суть понятия стратегия -- точно не в том, как именно она реализована. Класс (именно класс без объекта -- в программировании на шаблонах частое решение), объект, функция -- всё это может быть стратегией. Тут важна цель -- для чего, что стратегия делает. Скажем, работает объект с БД. Надо ли закрыть транзакцию в конце? Иногда надо, а иногда это просадит производительность, да ещё и ошибки может вызвать. И вот параметризация стратегией позволяет это настроить. А как что стратегия реализована -- вопрос десятый.
В немного более общем виде, стратегия — это элемент поведения, который передаётся в объект или функцию для кастомизации какого-то аспекта поведения. И далеко не всегда это одна функция, часто целое семейство. Когда-то давно в C++, скажем, базовый класс для объекта с подсчётом ссылок параметризовали классом-стратегией, определявшим правила многопоточной синхронизации для доступа к счётчику. А там минимум пара функций. Стратегией это, конечно, быть не переставало.
Имхо, сама история термина "бирюзовая компания" на русском совершенно позорна.
Во-первых, они ни капли не бирюзовые. Система кодирования цветов заимствована из модели AQAL Уилбера. И там в русском языке есть сложившаяся и устоявшаяся традиция переводить Teal как "изумрудный", а как бирюзовый переводить следующий, Turquoise. Так что для начала Teal organizations -- это изумрудные организации, но с лёгкой руки бывшего не в контексте первого переводчика мы уже получили то, что получили, традицию перевода термина, конфликтующую с традицией перевода литературы по сопряжённым областям.
Во-вторых, если вчитаться в описания организаций у Лалу (видно, что там устраняются иерархии) и в то, что собой представляют уровни AQAL, то и к изумрудному уровню эти структуры отношения не имеют, это всего лишь дальнейшее воплощение "зелёных" идей. Следующий же уровень, изумрудный (обозванный по ошибке бирюзовым), этой идеей не одержим, он достаточно спокойно выстраивает иерархии и достаточно гибко их меняет. "Зелёному" уровню вообще свойственна несколько нездоровая фиксация на идеях всеобщего равенства.
Я абсолютно уверен, что никаких "бирюзовых" или "изумрудных" организаций в бизнесе на сегодня нет и быть не может, ни в России, ни где-либо ещё. Более того, свойства организаций данного уровня пока не очень понятны. Но они точно не будут деиерархизированы. Гибкими -- вероятно. Находящими место людям с разным развитием -- да. Но помешанными на равенстве -- нет.
А вся эта традиция считать организации то ли бирюзовыми, то ли изумрудными -- результат хайпа, не имеющего под собой вообще никаких реальных оснований.
Вообще степень токсичного влияния зелёных идей трудно даже описать. Именно отсюда растут ноги бесчисленных заигрываний с персоналом, совершенно искаженных игр в псевдодемократию даже там, где она совершенно неуместна, и многое, многое другое. Половина Agile заражена этими идеями. Отсюда берутся команды, которые не в состоянии обеспечить хоть какую-то прозрачность и контролируемость работы, но при этом агрессивно претендуют на полную самоорганизацию и их право решать любые вопросы в пределах своей досягаемости. Отсюда берётся нарождающаяся традиция руководства, заигрывающего с подобными подчинёнными, и много чего ещё.
Диктатура плоха, спору нет. Но лучше ли ЭТО? Я сомневаюсь.
Да, тоже забавно читать рассуждения про бессмысленность ООП. Вполне рабочая парадигма до сих пор. Не единственная, и я бы не заигрывался в пуризм. Но стопроцентно живая. Просто нет смысла играть в неё в некоторых (обычно простых) случаях. На свете есть очень много вещей, которые просто реализуются функцией, и не надо натягивать их на ООП. Меня в своё время поразил раздолбайский подход, принятый в Python. Разумеется, ООП там поддерживается, и часто активно используется, но на нижнем уровне часто очень много сделано просто функциями без какой-либо потуги на ООП. К этому стилю я после многих лет C++ привыкал, но потом оценил. Впрочем, иерархии классов я там всё равно использую, просто только там, где это действительно проще и понятнее. Даже многие паттерны проектирования там принято реализовывать совсем иначе. Но и там ООП много. Некоторые абстракции всё-таки хорошо реализуется именно средствами ООП. Но не все.
Критики же ООП не понимают обычно, что если они использовали, скажем, наследование -- это не обязательно ООП. Если единственный мотив для этого наследования -- переиспользовать код, то речь о применении языковых механизмов поддержки ООП для проектирования, не являющегося объектно-ориентированным. В классическом ООП наследование всегда выражает отношения генерализации (общее-частное). Словом, нет с ООП никакой проблемы, кроме двух случаев -- кривого использования и стрельбы из пушки по воробьям (т.е. искусственного впихивания в парадигму простых вещей, совершенно в этой парадигме не нуждающихся).
Современное программирование, строго говоря, мультипарадигменное, как и большинство современных языков. Оно совершенно не ограничено ООП, что, впрочем, ООП не отменяет. Некоторые языки больше провоцируют применения ООП, некоторые меньше, но чуть не все поддерживают.
ООП на уровне языка со своими тремя китами (инкапсуляция, наследование, полиморфизм) очень удобно для описания НЕКОТОРЫХ абстракций. И существенно менее удобно для других. Собственно, в этом и ответ на вопрос, когда и кому нужно ООП.
И если для чего-то наиболее подходящей абстракцией будет функция, а не класс с методами, то ничего плохого в этом нет совершенно. Хотя многие базовые абстракции очень удобно оформлять как классы. ООП -- прекрасная штука, просто не стоит натягивать сову на глобус.
К слову, значительная часть даже стандартной библиотеки C++ -- это не вполне ООП, иногда даже вообще не ООП.
Если ООП понимать как обязательное к исполнению везде и во всём -- это кандалы. Зачем себя ограничивать раз и навсегда? Если как инструмент, очень неплохо решающий свои задачи удобного описания НЕКОТОРЫХ абстракций -- это совсем другое дело.
Если же говорить о паттерне Strategy, то весь этот "ужас" кажется излишними тяжестями до тех пор, пока вы не оказываетесь перед необходимостью кастомизировать какое-то действительно сложное поведение. Впрочем, и тут все зависит от ситуации и, кстати, языка. Если желаемое поведение состоит из одного действия, а не развесистого интерфейса, вполне может хватит, скажем, передачи простой функции. А где-то стратегию удобно делать параметром шаблона. Общая идея одна, а реализации совершенно разные.
И наконец, есть ООП как идея и есть поддержка механизмов ООП на уровне языка. Интересно, что эти языковые механизмы ООП можно использовать для программирования в стиле, который ООП вообще не является. Допустим, то же наследование для реализации частного случая, расширяющего базовый -- это именно ООП. А наследование для переиспользования функциональности класса -- это не ООП (но нередко хороший кодировочный трюк). Ну и наоборот, ООП на чистом C -- совершенно возможная (даже нередкая) вещь, просто приходится обходиться без языковых механизмов, которые в C++ есть.
Я видел в европейской компании это. И слово "нажать" можно употреблять по-разному. Я вообще не о диктаторстве. Я о псевдоаджайл-трансформациях с выпиливанием инструментов вертикального управления. Вообще никто не может от команды ничего потребовать. Есть PO, есть бэклог. PO не заинтересован, никакую общетехнологическую мелочь с уровня компании не пропихнуть. Или приходит аджайл-коуч, говорит -- трудности вижу такие-то, надо пробовать то-то (и нет, он их не на голове стоять просит). И они что, пробуют? Нет, пусть трудности очевидны, они говорят: нет, не хотим. Творят реально чёрт знает что, но нажать (не раздавить, а просто сказать: мы нашли вам коуча, поделайте некоторое время то, что он предложит), некому. У нас демократия.
И очень часто аджайл понимают именно так. "Всё решает команда, всё равны, никто нам не указ". Хотя реально идея была всего лишь "не дергай команду без нужды, дай им делать своё дело, справляются -- не трогай". И когда команда справляется и изначально может сорганизоваться, это отлично. А если нет? Некоторые команды надо реально учить самоорганизовываться.
Самое глупое, что в конце концов при долгой неэффективной работе всё равно всех разгонят по причине финансовой невыгодности.
Очень всё это напоминает рассуждения о дисфункциональную зелёном из книги Уилбера "Трамп и эпоха постправды".
Так-то правда, спору нет. Я бы таких начальников от подчинённых изолировал. Но в западных компаниях сейчас очень много обратного. Демократия, псевдоаджайл, мы самоорганизующаяся команда, не решай ничего за нас. И почти никаких средств нажать на них. Другая крайность, но, как говорил ИВ, "Оба хужэ!"
Сами проблемы реальны. В этом смысле со статьёй трудно не согласиться. А вот методы -- тут много вопросов.
Во-первых, создать систему тотальной слежки, анонимных жалоб и всеобщих KPI — это, на мой взгляд, значит породить такую же токсичную атмосферу, только в другом стиле. В европейских компаниях это очень популярно, но помогает довольно плохо. Хотя вроде тут и цели по SMART, и каналы для жалоб, и прочее, но толку, увы, немного. В лучшем случае вместо атмосферы вечных гладиаторских боёв формируется атмосфера секты. Может, это и лучше, но не так радикально, как хотелось бы.
Во-вторых, "обучить эмоциональному интеллекту" — это как? Научить можно максимум имитации некоторых его проявлений, что же до эмоционального интеллекта, то вы человеку принудительно 10 лет психотерапии назначите? А что в эти 10 лет делать? А если не пойдёт он в терапию? Да и терапия ведь не для всех работает. Тяжёлое НРЛ или явную социопатию (а история с орешками и изюмом похожа на проявление этих проблем, хотя, может, просто у человека нервный срыв) чёрта с два выйдет надёжно вылечить, обычно пациент не захочет так глубоко копать.
Трекание потраченного времени -- ересь полная. Я трекаю остаток оценок по задачам, и то только для burndown'а, чтобы понять заранее, что спринт пошёл не так. А кто там сколько потратил -- нафиг мне это вообще знать? Когда кто-то халявит, это и так видно, а гестаповскими методами проверять каждого -- только ухудшать ситуацию. Команда, с которой ты враг и для которой ты источник постоянных проверок, не будет работать эффективно. И зачем тогда этот разрушающий контроль? Дела испортить?
Не, ну, конечно, бывает разное. Низкооплачиваемый низкоквалифицированный труд, высокая текучка, человек -- винтик, всех легко заменить. Но это совершенно особый случай, и обычно работать в таком месте не слишком интересно, скорее всего, я, как аджайл-коуч, туда просто не пойду. Кому из нормальных людей интересно быть надсмотрщиком в концлагере?
Ааааа! Вот о чём речь. Что у некоего пользователя, под которым запущен скрипт, появились права. Но где гарантия, что появятся? Или что после чтения данных права не восстановят?
Оценка всегда вопрос непростой. Некоторые люди оценивать работу очень не любят, и часто приходится изрядно поработать, объясняя, что, дав ту или иную оценку, человек не несёт за неё жёсткой ответственности. И некоторым командам в моей практике это было очень непросто объяснить. Если применяется оценка остатка работ для построения burndown, совсем сложно.
Тем не менее, обычно я настаиваю на оценке и на оценке остатка на дейли. Естественно, не микроменеджмента ради (чего некоторые боятся), а для контроля того, успеваем ли, не надо ли что-то неважное выкинуть и т. п. О проблеме всегда комфортнее узнать заранее. То же, как каждый работает, команде обычно видно и так, для этого не надо портить жизнь всем микроменеджментом.
А вот к тому, как объяснять стори-поинты, я в итоге сформировал такой подход, что говорю, что это идеальные человеко-часы. Для расчёта длины спринта при этом вводится некий волшебный коэффициент, равный стоимости стори-поинта в человеко-часах. В качестве стартового значения я рекомендую 1.5, а обычно он в итоге колеблется от 1.3 до 1.8, точному вычислению не подлежит (точные вычисления тут вообще, имхо, утопия), подбирается экспериментально. Ошибок при оценке всегда много, но если оценка не является совсем бредовой, сумма оценок задач в спринте имеет распределение, сильно отличающееся от распределений оценок отдельных задач. Известно, что сумма многих равномерно распределенных случайных величин имеет распределение с острым пиком в середине, и чем этих величин больше, тем больше шансов на получение предсказуемой суммы. Если же исходные величины распределены не совсем равномерно и всё-таки имеют какой-то максимум в районе верной оценки, то с суммой всё обычно совсем хорошо.
Декомпозиция -- неплохой способ, и её в любом случае стоит делать, но всё-таки трудоемкость отдельных задач часто сильно варьируется. После декомпозиции я рекомендую обычно оценивать части.Вот с чем бывает очень много проблем -- это с тем, что даже в кросс-функциональной команде обычно нет такого, что люди кросс-функциональны. Те же тестировщики -- отдельный ресурс. В итоге я часто советую давать не одну оценку задаче, а две (бывает и больше, м но чаще всего две). Тут, правда, надо потратить ещё немало усилий, чтобы загрузить тестировщиков (обычно работающих после разработчиков) равномерно -- это отдельная повесть о куче хитрых трюков, вплоть до впихивания в спринт задач, которые никто не планирует довести до протестированности и деплоя: они должны быть реализованы в этом спринте и загрузить тестировщиков на начало следующего.
В общем, это мир таких плясок с бубном, что даже программирование как таковое бледнеет.
Слушайте, объясните мне, пожалуйста, каким образом успешное открытие файла на чтение скриптом служит маркёром того, что кто-то в него полез? В упор не пойму, что этот скрипт, собственно, проверяет. Если бы проверялось то, не создал ли кто-то эти файлы, я бы понял, это подобным образом проверить можно. Но почему успешное открытие на чтение говорит о том, что кто-то файл прочитал?
Справедливости ради, если команда имеет неформального лидера, это тоже случай самоорганизации. Но соглашусь, что часто под самоорганизацией ошибочно понимают полное всеобщее равенство и отсутствие иерархий, которое есть утопия.
Кросс-функциональные же и правда редки. Я давно перестал во многих случаях даже пытаться её добиться. Скажем, одна из команд: два тестера, три бекендера, фронтендер и саппортер, большинство -- по аутстаффингу и не очень надолго. И что, мне предлагается убедить их, что надо за счёт заказчика выровнять компетенции? Или чтобы этих выгнали и заменили? Такой бред я им не предложу.
Я бы сказал, что Скрам -- действительно не самоцель. В реальности приходится строить свой процесс, и он лишь напоминает Скрам, поскольку заимствовал оттуда многие черты.
Что же касается многих идей -- кросс-функциональности, частых релизов, то, увы, это действительно не всегда применимо. Самый радикальный пример -- это когда у вас продукт с 30-летней историей, большая часть которого создана не то что без всех этих Continuous Delivery, а из расчёта, что тестировщики глазами посмотрят. (Конечно, есть вещи, которые надо смотреть именно глазами, но когда 95% функциональности тестируется так, релиз даже каждые две недели -- утопия). Самое смешное, что и новые продукты часто создаются именно так, и ключевой вопрос архитектуры современных продуктов -- "как это непрерывно тестировать?" -- игнорируется с самого начала. И в итоге мы получаем ту же историю и ломаем рекомендуемый процесс под реальность.
Ломать процесс при этом именно приходится, выхода нет. Но жаль, что в эту, пардон, задницу, попадают новые продукты, а не 30-летние монстры с десятками миллионов строк кода, которых действительно могила исправит.
А уж когда на странные процессы внизу накручивается, пардон, какой-нибудь SAFe, смотреть на это часто и вовсе больно.
Нет, тогда не компьютеры сбоили часто, а система зависала часто по причине полного отсутствия защищённого режима в 8086 и 8088. Изоляция программ была совершенно невозможна, все использовали одно адресное пространство, могли выполнять любые инструкции процессора и делать что угодно, поэтому любой сбой в прикладном приложении обычно клал систему.
Правда, комбинация Ctrl-Alt-Del работала тоже не всегда. Если программа сама обрабатывала клавиатурный ввод без помощи BIOS или зависала, предварительно запретив прерывания (скажем, в обработчике прерывания), то через Ctrl-Alt-Del ничего было не добиться. Например, большинство игр, естественно, сами обрабатывали прерывания от клавиатуры.
Оценка сугубо по результатам тестов, конечно, лишена индивидуальности, спору нет. И система образования (даже сами вузы) во многих сферах сильно устарела, это тоже правда. Если хирургов и других медиков, скажем, надо всё-таки учить привычным образом, то большинство профессий вполне допускают и самостоятельное освоение. Это с одной стороны.
А с другой -- некий формальный барьер всё равно надо преодолеть. ЕГЭ, при всей своей нелепости, есть фильтр на мотивацию к учёбе, пусть и сильно несовершенный. И сдать его на приемлемом уровне 99% мотивированных учеников вполне в состоянии. Исключения есть: скажем, сдать русский с дисграфией сложно, а талантливый, например, математик или психолог может иметь такой дефект. Было бы хорошо, чтобы такие исключения обрабатывались как-то корректно. Однако вообще любая система отбора -- не без дыр. То, что было до ЕГЭ, тоже не было совершенно, но как-то же мы сдавали и поступали?
Да, давно пора снизить формализацию требований к образованию в тех областях, где это возможно (вот у медиков, повторюсь, точно нельзя, хирург не может учиться по онлайн-курсу). Думаю, это придёт. Но, увы, сейчас переходный период.
Во времена моего программистского детства почти 40 лет назад мы обычно не знали названий конкретных алгоритмов поиска пути, но знали две группы алгоритмов -- "поиск вглубь" (хороший пример -- рекурсивные алгоритмы), при котором ты просматривает путь сначала вглубь, потом вариации, и "поиск вширь", при котором идёшь от одной вершины и подсчитываешь цену пути от начала до набора просматриваемых в данный момент точек. Именно ко второй группе относится Ваш алгоритм.
Дальше на основе общей идеи этих групп можно конструировать алгоритмы под конкретную задачу, часто с серьёзными вариациями (например, для конкретной задачи часто нужен необычный порядок выборки вершины из набора просматриваемых). Остаётся прикинуть в каждом случае две основных характеристики алгоритма -- вычислительную сложность и (сейчас это реже надо смотреть) используемую память. Иногда -- для среднего и худшего случая отдельно. Вообще это всё очень забавный конструктор алгоритмов, в который раньше постоянно играли в олимпиадных задачах.
Да, многие так и думают. :-) Хотя реально это важнейшая вещь, часто куда важнее спринт ревью. И как-то у меня обычно люди реально говорят, что им нравится и не нравится в процессе, что пошло не так, что и как стоит попробовать иначе, и очень редко это отсутствие очистителя. :-) Именно по итогам ретроспектив можно процесс настраивать. Scrum -- это, имхо, в последнюю очередь ритуалы. Если некий ритуал мешает, мы его просто заменяем тем, что нам надо, и пусть хоть сто книжек возмущаются, именно в этом суть нормального вменяемого Agile, идеи которого в ориентации на реальность, а не на процессные правила.
В большинстве компаний Scrum вообще используют совершенно безумно, а потом удивляются, что люди выгорают и увольняются. Особенно меня умиляет желание сразу реализовать какой-нибудь SAFe в армейском стиле хождения строем. Но зовут варваров-консультантов, платят им миллионы и не думают, не фигню ли мы делаем. Это же во всём мире принято. :-)
А ещё в головах сеют полный бред типа "суть Agile в том, что всё решает команда". В плане принятия решений суть в том, что всё должны решать те, кто имеет компетенции для принятия именно этого решения, а не демократическое голосование. Часто это команда. Или команда + продакт овнер. Или ещё и представитель бизнеса, знающий нужный аспект. Или часть команды. Или даже конкретный человек. Но не некий "начальник" и не голосование людей, ничего не знающих о вопросе.
Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.
А я там выше как раз привёл пример. Элемент поведения -- это не одно действие, а определенный аспект того, что класс делает. Это может быть далеко не одно действие. Более того, в стратегии и объекты внутри могут быть (тот же объект синхронизации в приведенном ранее пример подсчёта ссылок). Для того, чтобы считать что-то стратегией важно то, что оно делает, а не то, как реализовано. Это уже детали конкретной стратегии.
Функция, естественно, может описывать поведение. Но, скажем, упомянутое выше "как синхронизировать доступ к счетчику ссылок" -- это вполне себе аспект поведения объекта. Хотя там -- минимум два метода, стратегия описывается классом, а в экземпляре класса ещё и объект синхронизации (под виндой, скажем, критическая секция) запрятан.
Вообще суть понятия стратегия -- точно не в том, как именно она реализована. Класс (именно класс без объекта -- в программировании на шаблонах частое решение), объект, функция -- всё это может быть стратегией. Тут важна цель -- для чего, что стратегия делает. Скажем, работает объект с БД. Надо ли закрыть транзакцию в конце? Иногда надо, а иногда это просадит производительность, да ещё и ошибки может вызвать. И вот параметризация стратегией позволяет это настроить. А как что стратегия реализована -- вопрос десятый.
В немного более общем виде, стратегия — это элемент поведения, который передаётся в объект или функцию для кастомизации какого-то аспекта поведения. И далеко не всегда это одна функция, часто целое семейство. Когда-то давно в C++, скажем, базовый класс для объекта с подсчётом ссылок параметризовали классом-стратегией, определявшим правила многопоточной синхронизации для доступа к счётчику. А там минимум пара функций. Стратегией это, конечно, быть не переставало.
Имхо, сама история термина "бирюзовая компания" на русском совершенно позорна.
Во-первых, они ни капли не бирюзовые. Система кодирования цветов заимствована из модели AQAL Уилбера. И там в русском языке есть сложившаяся и устоявшаяся традиция переводить Teal как "изумрудный", а как бирюзовый переводить следующий, Turquoise. Так что для начала Teal organizations -- это изумрудные организации, но с лёгкой руки бывшего не в контексте первого переводчика мы уже получили то, что получили, традицию перевода термина, конфликтующую с традицией перевода литературы по сопряжённым областям.
Во-вторых, если вчитаться в описания организаций у Лалу (видно, что там устраняются иерархии) и в то, что собой представляют уровни AQAL, то и к изумрудному уровню эти структуры отношения не имеют, это всего лишь дальнейшее воплощение "зелёных" идей. Следующий же уровень, изумрудный (обозванный по ошибке бирюзовым), этой идеей не одержим, он достаточно спокойно выстраивает иерархии и достаточно гибко их меняет. "Зелёному" уровню вообще свойственна несколько нездоровая фиксация на идеях всеобщего равенства.
Я абсолютно уверен, что никаких "бирюзовых" или "изумрудных" организаций в бизнесе на сегодня нет и быть не может, ни в России, ни где-либо ещё. Более того, свойства организаций данного уровня пока не очень понятны. Но они точно не будут деиерархизированы. Гибкими -- вероятно. Находящими место людям с разным развитием -- да. Но помешанными на равенстве -- нет.
А вся эта традиция считать организации то ли бирюзовыми, то ли изумрудными -- результат хайпа, не имеющего под собой вообще никаких реальных оснований.
Вообще степень токсичного влияния зелёных идей трудно даже описать. Именно отсюда растут ноги бесчисленных заигрываний с персоналом, совершенно искаженных игр в псевдодемократию даже там, где она совершенно неуместна, и многое, многое другое. Половина Agile заражена этими идеями. Отсюда берутся команды, которые не в состоянии обеспечить хоть какую-то прозрачность и контролируемость работы, но при этом агрессивно претендуют на полную самоорганизацию и их право решать любые вопросы в пределах своей досягаемости. Отсюда берётся нарождающаяся традиция руководства, заигрывающего с подобными подчинёнными, и много чего ещё.
Диктатура плоха, спору нет. Но лучше ли ЭТО? Я сомневаюсь.
Да, тоже забавно читать рассуждения про бессмысленность ООП. Вполне рабочая парадигма до сих пор. Не единственная, и я бы не заигрывался в пуризм. Но стопроцентно живая. Просто нет смысла играть в неё в некоторых (обычно простых) случаях. На свете есть очень много вещей, которые просто реализуются функцией, и не надо натягивать их на ООП. Меня в своё время поразил раздолбайский подход, принятый в Python. Разумеется, ООП там поддерживается, и часто активно используется, но на нижнем уровне часто очень много сделано просто функциями без какой-либо потуги на ООП. К этому стилю я после многих лет C++ привыкал, но потом оценил. Впрочем, иерархии классов я там всё равно использую, просто только там, где это действительно проще и понятнее. Даже многие паттерны проектирования там принято реализовывать совсем иначе. Но и там ООП много. Некоторые абстракции всё-таки хорошо реализуется именно средствами ООП. Но не все.
Критики же ООП не понимают обычно, что если они использовали, скажем, наследование -- это не обязательно ООП. Если единственный мотив для этого наследования -- переиспользовать код, то речь о применении языковых механизмов поддержки ООП для проектирования, не являющегося объектно-ориентированным. В классическом ООП наследование всегда выражает отношения генерализации (общее-частное). Словом, нет с ООП никакой проблемы, кроме двух случаев -- кривого использования и стрельбы из пушки по воробьям (т.е. искусственного впихивания в парадигму простых вещей, совершенно в этой парадигме не нуждающихся).
Современное программирование, строго говоря, мультипарадигменное, как и большинство современных языков. Оно совершенно не ограничено ООП, что, впрочем, ООП не отменяет. Некоторые языки больше провоцируют применения ООП, некоторые меньше, но чуть не все поддерживают.
ООП на уровне языка со своими тремя китами (инкапсуляция, наследование, полиморфизм) очень удобно для описания НЕКОТОРЫХ абстракций. И существенно менее удобно для других. Собственно, в этом и ответ на вопрос, когда и кому нужно ООП.
И если для чего-то наиболее подходящей абстракцией будет функция, а не класс с методами, то ничего плохого в этом нет совершенно. Хотя многие базовые абстракции очень удобно оформлять как классы. ООП -- прекрасная штука, просто не стоит натягивать сову на глобус.
К слову, значительная часть даже стандартной библиотеки C++ -- это не вполне ООП, иногда даже вообще не ООП.
Если ООП понимать как обязательное к исполнению везде и во всём -- это кандалы. Зачем себя ограничивать раз и навсегда? Если как инструмент, очень неплохо решающий свои задачи удобного описания НЕКОТОРЫХ абстракций -- это совсем другое дело.
Если же говорить о паттерне Strategy, то весь этот "ужас" кажется излишними тяжестями до тех пор, пока вы не оказываетесь перед необходимостью кастомизировать какое-то действительно сложное поведение. Впрочем, и тут все зависит от ситуации и, кстати, языка. Если желаемое поведение состоит из одного действия, а не развесистого интерфейса, вполне может хватит, скажем, передачи простой функции. А где-то стратегию удобно делать параметром шаблона. Общая идея одна, а реализации совершенно разные.
И наконец, есть ООП как идея и есть поддержка механизмов ООП на уровне языка. Интересно, что эти языковые механизмы ООП можно использовать для программирования в стиле, который ООП вообще не является. Допустим, то же наследование для реализации частного случая, расширяющего базовый -- это именно ООП. А наследование для переиспользования функциональности класса -- это не ООП (но нередко хороший кодировочный трюк). Ну и наоборот, ООП на чистом C -- совершенно возможная (даже нередкая) вещь, просто приходится обходиться без языковых механизмов, которые в C++ есть.
Я видел в европейской компании это. И слово "нажать" можно употреблять по-разному. Я вообще не о диктаторстве. Я о псевдоаджайл-трансформациях с выпиливанием инструментов вертикального управления. Вообще никто не может от команды ничего потребовать. Есть PO, есть бэклог. PO не заинтересован, никакую общетехнологическую мелочь с уровня компании не пропихнуть. Или приходит аджайл-коуч, говорит -- трудности вижу такие-то, надо пробовать то-то (и нет, он их не на голове стоять просит). И они что, пробуют? Нет, пусть трудности очевидны, они говорят: нет, не хотим. Творят реально чёрт знает что, но нажать (не раздавить, а просто сказать: мы нашли вам коуча, поделайте некоторое время то, что он предложит), некому. У нас демократия.
И очень часто аджайл понимают именно так. "Всё решает команда, всё равны, никто нам не указ". Хотя реально идея была всего лишь "не дергай команду без нужды, дай им делать своё дело, справляются -- не трогай". И когда команда справляется и изначально может сорганизоваться, это отлично. А если нет? Некоторые команды надо реально учить самоорганизовываться.
Самое глупое, что в конце концов при долгой неэффективной работе всё равно всех разгонят по причине финансовой невыгодности.
Очень всё это напоминает рассуждения о дисфункциональную зелёном из книги Уилбера "Трамп и эпоха постправды".
Так-то правда, спору нет. Я бы таких начальников от подчинённых изолировал. Но в западных компаниях сейчас очень много обратного. Демократия, псевдоаджайл, мы самоорганизующаяся команда, не решай ничего за нас. И почти никаких средств нажать на них. Другая крайность, но, как говорил ИВ, "Оба хужэ!"
Сами проблемы реальны. В этом смысле со статьёй трудно не согласиться. А вот методы -- тут много вопросов.
Во-первых, создать систему тотальной слежки, анонимных жалоб и всеобщих KPI — это, на мой взгляд, значит породить такую же токсичную атмосферу, только в другом стиле. В европейских компаниях это очень популярно, но помогает довольно плохо. Хотя вроде тут и цели по SMART, и каналы для жалоб, и прочее, но толку, увы, немного. В лучшем случае вместо атмосферы вечных гладиаторских боёв формируется атмосфера секты. Может, это и лучше, но не так радикально, как хотелось бы.
Во-вторых, "обучить эмоциональному интеллекту" — это как? Научить можно максимум имитации некоторых его проявлений, что же до эмоционального интеллекта, то вы человеку принудительно 10 лет психотерапии назначите? А что в эти 10 лет делать? А если не пойдёт он в терапию? Да и терапия ведь не для всех работает. Тяжёлое НРЛ или явную социопатию (а история с орешками и изюмом похожа на проявление этих проблем, хотя, может, просто у человека нервный срыв) чёрта с два выйдет надёжно вылечить, обычно пациент не захочет так глубоко копать.
Трекание потраченного времени -- ересь полная. Я трекаю остаток оценок по задачам, и то только для burndown'а, чтобы понять заранее, что спринт пошёл не так. А кто там сколько потратил -- нафиг мне это вообще знать? Когда кто-то халявит, это и так видно, а гестаповскими методами проверять каждого -- только ухудшать ситуацию. Команда, с которой ты враг и для которой ты источник постоянных проверок, не будет работать эффективно. И зачем тогда этот разрушающий контроль? Дела испортить?
Не, ну, конечно, бывает разное. Низкооплачиваемый низкоквалифицированный труд, высокая текучка, человек -- винтик, всех легко заменить. Но это совершенно особый случай, и обычно работать в таком месте не слишком интересно, скорее всего, я, как аджайл-коуч, туда просто не пойду. Кому из нормальных людей интересно быть надсмотрщиком в концлагере?
Ааааа! Вот о чём речь. Что у некоего пользователя, под которым запущен скрипт, появились права. Но где гарантия, что появятся? Или что после чтения данных права не восстановят?
Оценка всегда вопрос непростой. Некоторые люди оценивать работу очень не любят, и часто приходится изрядно поработать, объясняя, что, дав ту или иную оценку, человек не несёт за неё жёсткой ответственности. И некоторым командам в моей практике это было очень непросто объяснить. Если применяется оценка остатка работ для построения burndown, совсем сложно.
Тем не менее, обычно я настаиваю на оценке и на оценке остатка на дейли. Естественно, не микроменеджмента ради (чего некоторые боятся), а для контроля того, успеваем ли, не надо ли что-то неважное выкинуть и т. п. О проблеме всегда комфортнее узнать заранее. То же, как каждый работает, команде обычно видно и так, для этого не надо портить жизнь всем микроменеджментом.
А вот к тому, как объяснять стори-поинты, я в итоге сформировал такой подход, что говорю, что это идеальные человеко-часы. Для расчёта длины спринта при этом вводится некий волшебный коэффициент, равный стоимости стори-поинта в человеко-часах. В качестве стартового значения я рекомендую 1.5, а обычно он в итоге колеблется от 1.3 до 1.8, точному вычислению не подлежит (точные вычисления тут вообще, имхо, утопия), подбирается экспериментально. Ошибок при оценке всегда много, но если оценка не является совсем бредовой, сумма оценок задач в спринте имеет распределение, сильно отличающееся от распределений оценок отдельных задач. Известно, что сумма многих равномерно распределенных случайных величин имеет распределение с острым пиком в середине, и чем этих величин больше, тем больше шансов на получение предсказуемой суммы. Если же исходные величины распределены не совсем равномерно и всё-таки имеют какой-то максимум в районе верной оценки, то с суммой всё обычно совсем хорошо.
Декомпозиция -- неплохой способ, и её в любом случае стоит делать, но всё-таки трудоемкость отдельных задач часто сильно варьируется. После декомпозиции я рекомендую обычно оценивать части.Вот с чем бывает очень много проблем -- это с тем, что даже в кросс-функциональной команде обычно нет такого, что люди кросс-функциональны. Те же тестировщики -- отдельный ресурс. В итоге я часто советую давать не одну оценку задаче, а две (бывает и больше, м но чаще всего две). Тут, правда, надо потратить ещё немало усилий, чтобы загрузить тестировщиков (обычно работающих после разработчиков) равномерно -- это отдельная повесть о куче хитрых трюков, вплоть до впихивания в спринт задач, которые никто не планирует довести до протестированности и деплоя: они должны быть реализованы в этом спринте и загрузить тестировщиков на начало следующего.
В общем, это мир таких плясок с бубном, что даже программирование как таковое бледнеет.
Слушайте, объясните мне, пожалуйста, каким образом успешное открытие файла на чтение скриптом служит маркёром того, что кто-то в него полез? В упор не пойму, что этот скрипт, собственно, проверяет. Если бы проверялось то, не создал ли кто-то эти файлы, я бы понял, это подобным образом проверить можно. Но почему успешное открытие на чтение говорит о том, что кто-то файл прочитал?
Справедливости ради, если команда имеет неформального лидера, это тоже случай самоорганизации. Но соглашусь, что часто под самоорганизацией ошибочно понимают полное всеобщее равенство и отсутствие иерархий, которое есть утопия.
Кросс-функциональные же и правда редки. Я давно перестал во многих случаях даже пытаться её добиться. Скажем, одна из команд: два тестера, три бекендера, фронтендер и саппортер, большинство -- по аутстаффингу и не очень надолго. И что, мне предлагается убедить их, что надо за счёт заказчика выровнять компетенции? Или чтобы этих выгнали и заменили? Такой бред я им не предложу.
Я бы сказал, что Скрам -- действительно не самоцель. В реальности приходится строить свой процесс, и он лишь напоминает Скрам, поскольку заимствовал оттуда многие черты.
Что же касается многих идей -- кросс-функциональности, частых релизов, то, увы, это действительно не всегда применимо. Самый радикальный пример -- это когда у вас продукт с 30-летней историей, большая часть которого создана не то что без всех этих Continuous Delivery, а из расчёта, что тестировщики глазами посмотрят. (Конечно, есть вещи, которые надо смотреть именно глазами, но когда 95% функциональности тестируется так, релиз даже каждые две недели -- утопия). Самое смешное, что и новые продукты часто создаются именно так, и ключевой вопрос архитектуры современных продуктов -- "как это непрерывно тестировать?" -- игнорируется с самого начала. И в итоге мы получаем ту же историю и ломаем рекомендуемый процесс под реальность.
Ломать процесс при этом именно приходится, выхода нет. Но жаль, что в эту, пардон, задницу, попадают новые продукты, а не 30-летние монстры с десятками миллионов строк кода, которых действительно могила исправит.
А уж когда на странные процессы внизу накручивается, пардон, какой-нибудь SAFe, смотреть на это часто и вовсе больно.
Нет, тогда не компьютеры сбоили часто, а система зависала часто по причине полного отсутствия защищённого режима в 8086 и 8088. Изоляция программ была совершенно невозможна, все использовали одно адресное пространство, могли выполнять любые инструкции процессора и делать что угодно, поэтому любой сбой в прикладном приложении обычно клал систему.
Правда, комбинация Ctrl-Alt-Del работала тоже не всегда. Если программа сама обрабатывала клавиатурный ввод без помощи BIOS или зависала, предварительно запретив прерывания (скажем, в обработчике прерывания), то через Ctrl-Alt-Del ничего было не добиться. Например, большинство игр, естественно, сами обрабатывали прерывания от клавиатуры.
Оценка сугубо по результатам тестов, конечно, лишена индивидуальности, спору нет. И система образования (даже сами вузы) во многих сферах сильно устарела, это тоже правда. Если хирургов и других медиков, скажем, надо всё-таки учить привычным образом, то большинство профессий вполне допускают и самостоятельное освоение. Это с одной стороны.
А с другой -- некий формальный барьер всё равно надо преодолеть. ЕГЭ, при всей своей нелепости, есть фильтр на мотивацию к учёбе, пусть и сильно несовершенный. И сдать его на приемлемом уровне 99% мотивированных учеников вполне в состоянии. Исключения есть: скажем, сдать русский с дисграфией сложно, а талантливый, например, математик или психолог может иметь такой дефект. Было бы хорошо, чтобы такие исключения обрабатывались как-то корректно. Однако вообще любая система отбора -- не без дыр. То, что было до ЕГЭ, тоже не было совершенно, но как-то же мы сдавали и поступали?
Да, давно пора снизить формализацию требований к образованию в тех областях, где это возможно (вот у медиков, повторюсь, точно нельзя, хирург не может учиться по онлайн-курсу). Думаю, это придёт. Но, увы, сейчас переходный период.
Во времена моего программистского детства почти 40 лет назад мы обычно не знали названий конкретных алгоритмов поиска пути, но знали две группы алгоритмов -- "поиск вглубь" (хороший пример -- рекурсивные алгоритмы), при котором ты просматривает путь сначала вглубь, потом вариации, и "поиск вширь", при котором идёшь от одной вершины и подсчитываешь цену пути от начала до набора просматриваемых в данный момент точек. Именно ко второй группе относится Ваш алгоритм.
Дальше на основе общей идеи этих групп можно конструировать алгоритмы под конкретную задачу, часто с серьёзными вариациями (например, для конкретной задачи часто нужен необычный порядок выборки вершины из набора просматриваемых). Остаётся прикинуть в каждом случае две основных характеристики алгоритма -- вычислительную сложность и (сейчас это реже надо смотреть) используемую память. Иногда -- для среднего и худшего случая отдельно. Вообще это всё очень забавный конструктор алгоритмов, в который раньше постоянно играли в олимпиадных задачах.
Да, многие так и думают. :-) Хотя реально это важнейшая вещь, часто куда важнее спринт ревью. И как-то у меня обычно люди реально говорят, что им нравится и не нравится в процессе, что пошло не так, что и как стоит попробовать иначе, и очень редко это отсутствие очистителя. :-) Именно по итогам ретроспектив можно процесс настраивать. Scrum -- это, имхо, в последнюю очередь ритуалы. Если некий ритуал мешает, мы его просто заменяем тем, что нам надо, и пусть хоть сто книжек возмущаются, именно в этом суть нормального вменяемого Agile, идеи которого в ориентации на реальность, а не на процессные правила.
В большинстве компаний Scrum вообще используют совершенно безумно, а потом удивляются, что люди выгорают и увольняются. Особенно меня умиляет желание сразу реализовать какой-нибудь SAFe в армейском стиле хождения строем. Но зовут варваров-консультантов, платят им миллионы и не думают, не фигню ли мы делаем. Это же во всём мире принято. :-)
А ещё в головах сеют полный бред типа "суть Agile в том, что всё решает команда". В плане принятия решений суть в том, что всё должны решать те, кто имеет компетенции для принятия именно этого решения, а не демократическое голосование. Часто это команда. Или команда + продакт овнер. Или ещё и представитель бизнеса, знающий нужный аспект. Или часть команды. Или даже конкретный человек. Но не некий "начальник" и не голосование людей, ничего не знающих о вопросе.
Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.