TL;DR: Индустрия Agile консалтинга переупаковывает философию, изначально ориентированную на человека и технологии, в стандартизированную, всепогодную методологию по снижению проектных рисков. После того, как Agile продали управленческим огранизация, их менеджеры среднего звена превращают Agile в современную версию тейлоризма для работников умственного труда . Помимо этого метауровня, причины, по которым инженеры презирают Agile, можно разделить на пять категорий: управление, манипуляции, мониторинг, технологии и командная работа.
Проблемы, по которым инженеры презирают Agile
Когда я написал статью Agile Failure Patterns In Organizations, резюмируя типичные анти-паттерны применения Аgile в организациях, я был удивлен когда увидел, какое внимание она получила на HN.
Тогда я начал больше копаться в этой теме. До этого я был хорошо осведомлен о проблемах в отношении Agile, с которыми сталкиваются разработчики продуктов. Вы мечтаете о месте, похожем на Spotify, где вы можете работать, создавать продукты, которые нравятся клиентам, а действительности вы застреваете на своего рода позиции Jira-обезьянки, создавая истории пользователей.
Таким образом инженеры всегда казались мне естественными союзниками по веской причине. Разве вам не хочется получить полномочия, делать значимую работу и иметь цель в своей профессиональной жизни?
Неудивительно, что среди инженеров есть немало открытых критиков. Не поймите меня неправильно: не все инженеры презирают Agile. Но они высказывают серьезные опасения, которые можно разделить на пять категорий:
I. Контроль
Менеджмент среднего звена не желает отказываться от контроля ради расширения возможностей команд, а между тем такой отказ способствовал бы созданию обучающейся организации. Как результат сохранения контроля, идеал Agile о прозрачности и свободной передаче информации внутри организации в конечном итоге приводит к усилению надзора.
Подробнее об аспекте Agile-микроменеджмента: Agile Micromanagement in the Era of Autonomy, Mastery and Purpose.
II. Манипулирование
Преследование личных интересов также побуждает нанимать внешних консультантов; менеджмент среднего звена делает это для того, чтобы подкрепить свою точку зрения о том, чем является правильный Agile-процесс. И подкрепляет менеджмент среднего свою точку зрения о правильности путем следования «правилам» -- это известно как Agile карго-культ.
Нельзя сказать, что этот метод полностью игнорирует принцип Щю-Ха-Ри, используемый для изучения новой техники:
Здесь основная идея заключается в том, что при обучении концепции вы должны перестроить свой стиль преподования к тому, в каком понимании находится учащийся, и к тому, что прогресс следует общей схеме. На ранних этапах обучения основное внимание уделяется имитации конкретных шагов, затем акцент смещается на понимание принципов и, наконец, на самостоятельную инновацию.
Скорее, он начинается с применения «правил» на первом этапе, а затем продолжает их придерживаться, игнорируя второй и третий этапы. Поступая так, скелет Agile'a превращается в еще один стиль управления, который призывает следовать плану - только через более короткие промежутки времени, называемые спринтами.
III. Надзирательство
Механика Agile применяется всякий раз, когда это выгодно, но сама культура при этом не изменяется. В случае прозрачности и метрик, новый уровень информированности ведет к надзирательству и, в конечном итоге, к микроменеджменту. Тем самым, прозрачность имеет обратный эффект, создавая уязвимость вместо возможностей.
Важнейшими показателями Agile являются story points и скорость, а Jira выступает как проявление вытекающих из этого бюрократических накладных расходов: заведите тикеты на все что возможно, чтобы сделать производительность каждого инженера видимой.
Делая «технологию» видимой для нетехнических людей, это позволяет им получить своего рода "управленческий контроль над территорией", который они не могли осуществлять ранее.
Поверх всего этого лежат принудительные обязательства, при этом нет никаких полномочий на их исполнение. Таким образом, такие принципы, как расширение прав и возможностей команды, лидерство с помощью ЦКР (Цели и Ключевые Результаты) и лидерство в сфере услуг, превращаются в пустые обещания, в то время как всем заправляет микроменеджмент.
IV. Технология
Agile не в состоянии обеспечить, как обещано в Манифесте Agile, разработку, ведомую инженерами. Решения по-прежнему принимаются людьми, которые не разбираются в технологиях. В большинстве случаев сюда входят владелец продукта, а также менеджеры среднего звена или бизнес-аналитики.
Agile также делает технический долг неизбежным, поскольку командам необходимо выполнять каждый спринт, и желательно таким образом, чтобы обязательства соответствовали скорости -- чтобы таким образом упростить для менеджмента планирование и снижение рисков.
V. Работа в команде
В Agile нет места для личности. Он не учитывает трудовой стаж и личный рост отдельного инженера, поскольку больше нет техлидов.
Вместо того принципа «индивидуумы и взаимодействие важнее процессов и инструментов», Agile снова превращает отдельных разработчиков в винтики машины, создавая одноразовые клоны в рамках более или менее анонимного процесса. Что также является причиной перетасовки членов команды в срочном порядке.
Все это способствует тому, что теряется чувство собственности: проект - это просто список задач, предоставленных людьми из бизнеса, разделенный между собой последовательными временными рамками, также известными как спринты или итерации. В этом и есть причина того, почему теряется увлеченность проектами.
Несмотря на всю потерю чувства собственности, ожидается, что члены команды будут активно участвовать в церемониях: от отнимающих много времени стендапов и уточнений бэклога, до ретроспектив -- ритуалах «самосовершенствования», основанных на спринтах.
Что вы думаете?
Можете ли вы научить старого (менеджмент-) пса, прошедшего социализацию в командно-административной среде, новым трюкам Agile?
Во-первых, я считаю, что есть уловка 22: «хороший менеджер» по традиционным стандартам определяется тем, что он знает, что делать и как решать задачу.
А если новая идея требует прямо противоположного: признать, что менеджер не знает? Что, если речь идет о о том, чтобы быть открытым для обучения, экспериментов и неудач, а также о предоставлении командам возможности найти решение, а не предоставить его команде самостоятельно?
Итак, застряли ли мы в Agile карго-культе на целую вечность? Или он пройдет мимо, как и другие причуды менеджмента? Или мы сможем развернуть лодку?
Лично я все еще верю в подход Джорджа С. Паттона: «Не говорите людям, как делать, говорите им, что делать, и позвольте им удивить вас своими результатами».
Что вы думаете на этот счет?
Для дальнейшего чтения
Если вы хотите глубже разобраться в проблемах, по которым инженеры презирают Agile, я рекомендую в качестве отправной точки следующие публикации и видео:
Энди Хант: Провал Agile
Майкл О. Черч: Почему Agile и в особенности Scrum внушают ужас
ayasin: Agile - это новый водопад
Гарри Харролд, Руперт Редингтон: Апокриф по Agile и Ad-Hoc манифест
Публикации по теме
Паттерны провала Agileв организациях
Почему Agile превращается в микроменеджмент
Найм: 38 вопросов на собеседовании для скрам-мастера, чтобы избежать Agile-самозванцев
Комментарии (129)
Fi1osof
28.09.2021 02:43+2Нельзя сказать, что этот метод полностью игнорирует принцип Щю-Ха-Ри, используемый для изучения новой техники:
Здесь основная идея заключается в том, что при обучении концепции вы должны перекроить свой стиль преподования к тому, в каком понимании находится учащийся, и к тому, что прогресс следует общей схеме. На ранних этапах обучения основное внимание уделяется имитации конкретных шагов, затем акцент смещается на понимание принципов и, наконец, на самостоятельную инновацию.
Забавно :) Только вот пару дней назад своему ученику писал:
Стадия 1. Научиться делать так, как сказано.
Стадия 2. Понять почему это работает и почему это правильно
Стадия 3. Научиться это менять и делать по-другому.
Если ты не готов в Стадию 1, то ничего не получится. Я устану отвечать на разрозненные вопросы, которые никак не укладываются в общую канву.
Оказывается, это ShuHaRi))
S-e-n
28.09.2021 20:37Стадия 2 невозможна до стадии 3. Невозможно понять, что что-то правильно (или неправильно), пока не попытаешься сделать по-другому.
На стадии 2 можно только Уверовать, но никак не понять.Fi1osof
29.09.2021 05:29Именно что можно и нужно. Речь сейчас не о проектах типа "Подтянул джуна на совместную разработку убийцы гугла". Речь о простых базовых решениях. Так вот на первой стадии ученик еще вообще ничего не понимает. Ему даешь тестовые уроки, он читает в них теорию, кое-как подставляет решение, чтобы тест прошел успешно, и часто вообще не понимает что тут к чему (просто получается из задачи и требований вычленить что надо сделать). Но переходит к другому уроку и прошлый забывает сразу.
На второй стадии он хотя бы может уже разобрать решение, понять что здесь происходит (здесь массивы создаются, здесь сввойства объекту присываиваются и т.п. и т.п.). Он уже начинает понимать почему при работе со строками одни методы используются, а на числах другие. Но пока что он просто это понимает. Когда ему говоришь "А сделай так, чтобы результат был тот же, но использовать совсем другие методы". Вот тут он может вообще ничего не придумать. И это нормально.
Ну в про третий уровень можно и не говорить, там свобода творчества.
И все это я не просто так говорю. Я занимаюсь обучением программистов и все это довольно четко вижу на практике.
ivankudryavtsev
28.09.2021 17:14Нет, именно, что 90% труда отделяют его от конца таблицы, потому что 10% таланта там есть у всех. Так и тут, пусть у тебя нет 10% таланта, но твои 90% труда позволят тебе делать работу хорошо.
Ой, ну бросьте, так и про программистов можно говорить. И что 95% посредственностей теперь уволить и в дворники перевести.
Filmaniko
28.09.2021 07:07+2Я не верю во все эти гибкие методологии. Я верю в менеджмент, как смысл жизни, как подход к любой проблеме тебя окружающей. Менеджерами не становятся ими рождаются. В эталонном менеджере помимо хватки, разумности, рассудительности и дальнозоркости должны присутствовать такие качества как несгибаемость и конечно же харизма. Ну нельзя брать на работу менеджера с несколькими сертификатами о прохождении курсов, парочкой проектов. За долгие годы общения с МП при первом собеседовании, либо встрече определяю грамотный специалист передо мной или просто зубрилка. Внешний вид, уверенность, чёткость фраз, горящие глаза. Вот это всё делает проект успешным.
Agile, Scrum и тому подобные методологии лишь подспорье хорошему руководителю. Сам периодически перечитываю литературу, что-то черпаю для себя. Но слепо верить во всё что написано это глупо. Тикеты можно исключить, спринты сделать более рациональными и гибкими по времени. В общем согласен с автором. В погоне за идеальным подходом многие из нас стали заложниками этих манифестов. Хотя в советском союзе было всё тоже самое, только называлось по другому. А люди строили БАМ, воздвигали здания и перемещали целые ЦЕХА. Просто должна душа гореть и желание бить ключом. Остальное либо приложится либо придёт само.
ivankudryavtsev
28.09.2021 07:14+3Менеджеры бывают разные и по стилю и по темпераменту и по навыкам, по скоупу ответственности, по энергетике. И я не согласен, что менеджерами рождаются - это чушь. Проводя параллель, любой спортсмен скажет, что талант и тренировки это 10% и 90%.
anonymous
00.00.0000 00:00
dimskiy
28.09.2021 11:22+3В эталонном менеджере помимо хватки, разумности, рассудительности и дальнозоркости должны
… а еще, он непременно должен уметь летать!
Те же самые обычные люди там, совершенно ни чем не лучше и не умнее остальных :) Все с теми же комплексами, затыками и иллюзиями.
Aleks_ja
28.09.2021 17:43+2А в скраме нет такой роли "менеджер". Хоть я и прекрасно понимаю, про что вы, однако считаю, что скрам и вытягивает команды, в которых нет хороших менеджеров. Просто следуйте процессу как умеете и что-нибудь более-менее хорошее получится.
А вот в waterfall даже если вы крутой менеджер, у вас всё равно будут пропущенные дэдлайны и чэндж реквесты.
usa_habro_user
28.09.2021 18:06+2А в скраме нет такой роли "менеджер".
И, кстати, даже такой "сакральной" роли, как "тимлид" тоже нет. А ведь очень часто тут, на хабре, и не только, приходится встречать людей, утверждающих, что уж они-то в скраме "собаку съели", но постоянно упоминающих "тимлидов" ("да мы по чистому скраму уже больше 5 лет работаем, вот тут есть наш тимлид и прожект-менеджер, они подтвердят!")
ivankudryavtsev
28.09.2021 07:08+4Не знал до сегодняшнего дня что инженеры презирают Agile. Я не презираю, среди моих знакомых, насколько я знаю, тоже никто презрительно об Agile не отзывался. Нормально делай, нормально будет.
Проблема не в Agile или другой технологии, а когнитивных искажениях и эгоизме участников процесса.
mad_nazgul
28.09.2021 07:38+9"Отцы основатели" Agile забыли законы Мерфи.
"Если что-то может быть сделано не правильно, это будет сделано не правильно."
Точно так же и с Agile.
Его понимают не правильно, не потому что "люди плохие", а потому что Agile (принципы Agile) спроектирован плохо.
Ну или "Благими намерениями выстелена дорого в Ад".
Так что Agile идет в "правильном" направлении. :-)
kantocoder Автор
04.10.2021 22:54А вы поинтересуйтесь, кем являются отцы-основатели agile и сколько из них разработчиков.
А так да, Вы правы. Есть такой принцип дизайна интерфейсов: интерфейс нужно делать таким, чтобы им было легко пользоваться правильно, и трудно -- неправильно. А agile'ом в точности до наоборот.
На самом деле проблема глубже. Похоже что ВСЕ гибкие методологии (и XP, и RAD) не могут быть использованы для создания сложных продуктов и для систем, критических к безопасности. А поскольку все больше и больше инфраструктуры переходит на IT, аgile как минимум не нужен, а как максимум -- просто опасен.
Admz
28.09.2021 07:59С помощью Agile некоторые "эффективные менеджеры" пытаются управлять, и чем хуже его менеджерские качества тем упорнее он будет натсаивать на "праведности" agile. Зачастую средний состав прогибает людей под методику, а не наоборот методику под людей. Agile - это всего лишь один из инструментов, который можно перестроить под свою специфику и пользоваться им. А можно гвозди забивать, как это делают некоторые.
Story points - может "этапы задачи", не?
elektroschwein
28.09.2021 09:45Story points - может "этапы задачи", не?
"Эту задачу команда оценила в десять этапов, а вон ту -- в сорок", так что-ли? :)
Areso
28.09.2021 09:58+1Если один этап принять равным одному дню...
Но тогда уж 'подходов' :)
5 подходов и я справлюсь! - звучит, как утверждение сильного программиста.
vgglow
28.09.2021 12:16Это как естественные и суррогатные ключи в БД.
Зачем вводить искусственные единицы измерения, если имеются естественные и понятные всем дни, часы, недели? Не понимаю и никогда не пойму.
tmin10
29.09.2021 18:17Это же фича скрама: число часов у нас постоянное, а число стори поинтов в спринте может варьироваться и калиброваться в процессе спринтов: не успели сделать всё за спринт? Уменьшаем общее число стори поинтов команды и пробуем снова. Осталось свободное время? Увеличиваем число стори поинтов. Так вырабатывается ритм команды.
Конечно же при условии, что команда научилась как-то в этих стори поинтах оценивать задачи более-менее одинаково.
elektroschwein
28.09.2021 09:43+2Есть знаменитая книжка про SCRUM под названием "Art of doing twice the work", и я конечно понимаю, что имели в виду авторы этим названием, но иногда возникает впечатление, что ближе к реальности что-то типа "Art of forcing developers to do twice the work".
А в остальном, как уже сказали, все зависит от менеджера и от команды. Если менеджер тупой и команда неразумная, то будет карго-культ, а если делать все нормально, то agile-правила будет проанализированы, отфильтрованы и адаптированы к специфике конкретного проекта.
vassabi
28.09.2021 10:17опять же - кто платит "индустрии Agile консалтинга" ? Программисты\инженеры ?
Увы, поток денег идет от тех, кто хочет снизить свои риски, поэтому даже немного странно удивляться, что представленный сам себе, он "переупаковывает философию, изначально ориентированную человека и на технологии, в стандартизированную, всепогодную методологию по снижению проектных рисков"
Всё по классике: "если вам что-то дают бесплатно, то товар - это вы".
А чтобы такого не случалось, команде придется заплатить своими усилиями по освоению + подгонке по месту + внедрению и поддержке, чтобы инструмент служил команде, а не вышестоящему менеджменту...
ksbes
28.09.2021 11:09-1Если менеджер умный и команда разумная, то им вообще не нужны никакие методики — они так всё сделают хорошо, выработав наиболее оптимальные для текущих условий правила (и не раздумывая меняя их при смене условий). Мне довелось полгодика работать в такой команде — золотое время.
А все эти методики — водопады, ГОСТЫ, agile нужны именно чтобы «утилизировать» не самый лучший человеческий материал, которого на несколько порядков больше, чем «супермегапрофи». Т.е. исполнители в них изначально должны закладываться не самого лучшего «качества» (т.е. не особо заинтересованными, преследующими эгоистичные интересы и т.д.). Любая методика организации всегда будет в большинстве своём исполняться в режиме «карго-культа». Армейский принцип.
Вопрос только насколько эффективно этот «карго-культ» ведёт к желаемому результату и ведёт ли вообще.
A1054
28.09.2021 12:57Вы правы. Это напоминает закон Гудхарта. Или принцип дополнительности в квантах.
DigitalBerd
28.09.2021 10:49+1Проблема этой статьи в том, что человек тупо перевёл с английского какую-то чушь, не разобравшись. Думал рейтинга и кармы нафармить с минимальными трудозатратами - а в итоге сел в лужу.
Для разработки ПО, аджайл - одна из самых лучших МЕТОДОЛОГИЙ разработке. То, что не все могут в её реализацию - это другой вопрос:
Менеджеры продавливают свою оценку трудозатрат.
"Решения по-прежнему принимаются людьми, которые не разбираются в технологиях. "
Многие проблемы вообще надуманы.
Да взять те же деили митинги - раньше меня бесило на них время тратить, когда я поработал тимлидом - понял, что без них гораздо сложнее работать.
Paskin
28.09.2021 11:10Там и автор оригинала (при всех его регалиях) просто жжет огнем про story points и скорость. Я-то, грешный, думал что Agile - это для того, чтобы научиться точно оценивать
как быстро можно будет передать проект в Индиювремя и стоимость воплощения тех или иных идей бизнеса...
solaris_n
28.09.2021 11:20Думаю, что последнее обновление Скрам Гайда постаралось учесть многие моменты из данной статьи.
MAXH0
28.09.2021 11:22ИМХО (на правах человека 5 лет пытающегося разобраться с Agile).
Agile божественно великолепен, но он основан на ценностях. Если команда не в полной мере разделяет ценности, то начинаются проблемы и карго-культ. Попытки навязать ценности на основании повторения ритуалов и терминологии карго-культа, возникает унылое сектанство. Демонстрацией этого процесса служит холивар развернувшийся в первом же комменте.
Итак, @kantocoder был приглашен НЛО буквально вчера. И ему за две статьи критикующих Agile уже слили карму в минуса. Agile не догма, а руководство к действию. Он не может быть свободен от критики.
A1054
28.09.2021 13:07+1Agile божественно великолепен, но он основан на ценностях. Если команда не в полной мере разделяет ценности
Но тут возникает вопрос, насколько такие команды часто встречаются. Не исчезают ли они по мере роста компании. И способствует ли Agile сохранению мотивации или наоборот.
MAXH0
28.09.2021 16:24-1Опять же сугубое ИМХО, но вы совершенно правы. По мере роста они исчезают. Agile это уровень стартапа. Для больших возможно поток создания ценности Тойоты и прочий кайдзен, не знаю...
Мой огородик, который я копаю по Agile мал и ни как не связан с крупными компаниями. Я пытаюсь внести в образование Agile так, чтобы не учить плохому и не множить карго-культов. Надеюсь, что не очень быстро, но получается. Главное понять, что Agile это не о листочках приклеенных скотчем к доске...
olehorg
28.09.2021 11:26+8инженеры чудесно работают в Agile-окружении - если это и правда Agile.
Фишка в том что Agile - это НЕ инструмент инженера. При любом подходе к разработке у инженера будут задачи и тикеты. Agile - это инструмент менеджмента и взаимодействия с заказчиком.
Для начала, ценности Agile должен разделять заказчик. Это юрист и главбух заказчика (заодно с ЛПРом - лицом, принимающим решения) должны разделять убеждения что (копипаста):
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Во-вторых, ценности Agile должен разделять менеджмент, особенно непосредственные руководители инженеров. Инженеры очень хорошо чувствуют различия между декларируемым на тренингах и реальностью - именно это ощущение фальши инженеры презирают.
А Agile - в нем нет ничего плохого. Нормальный инструмент для определенных условий.
sshikov
28.09.2021 22:36-1Если вы заметили, в названии статьи инженеры, а в тексте — почти везде менеджмент. Ну т.е. прям с первого пункта:
I. Контроль
Менеджмент среднего звена не желает отказываться от контроля…
И где тут инженеры, которые ненавидят?
Поэтому на мой взгляд, все что в посте написано — по большей части просто натягивание совы на глобус.
dimoff66
28.09.2021 14:01Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Да, agile - Это плохая архитектура, это недостаток времени на вдумчивую разработку, это вечная гонка под минимальные стандарты и отсутствие творчества, так как часы на творчество менеджеры не предусмотрели, и с заказчиком что-то что предлагается командой, обсуждают они неохотно. Это бессмысленные дейли, где люди с постными физиономиями вынуждены выслушивать кучу информации, которая им не нужна, будучи вырванными из естественного внутреннего ритма разработки.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками. И это посредничество пользы разработке не приносит.Angmarets
28.09.2021 14:08+1Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Негатив к идее и негатив к гуглтранслейту с неуклюжей попыткой изобрести свои "сюжетные точки" - разные вещи. Тем более голосовать могут все, а менять карму - нет.
Shatun
28.09.2021 14:49+2Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Минусы неставил, но могу сказать почему мне статья ненравится.
Автор везде пишет про agile, но непонимает что это такое, в основном говоря про скрам. Например пункты про стори поинты, спринты, ретро-откуда они взялись в аджайле? Это характерно для скрама как вида аджайла, но в статье про скрам вообще ничего нету. Я например больше люблю канбан, без всяких стори поинтов и спринтов-согласитесь это довольно распростарненная практика. И это вполне аджайл.
Также некоторые недостатки оочень сомнительно описаны. Например про тикеты в джире-"имейте тикет на все и вся" -откуда это вообще взялось, почему в аджайле(или скраме, т.к. непонятно про что именно пишет автор) тикетов больше, с чем сравнивается и почему это плохо? Не могу сказать что в вотрефоле например тикетов меньше, причем у них более сложный жизненный цикл обычно.
Sergey-Titkov
28.09.2021 17:38Пригнувшись, и очень тихо. А Канбан-метод он как бы не аджайл...
Shatun
28.09.2021 18:15Почему?
Как минимум согласно литературы канбан относят к аджайлу.
Sergey-Titkov
28.09.2021 19:23Канбан-метод не требует соблюдать или разделять ценности аджайла.
Просто начните с того что есть сейчас, а куда вы придете, ну возможно разные варианты.
Соответственно, поэтому канабан это не аджайл.
Так же говориться на сайте канбан университета.
sshikov
28.09.2021 22:46-1>Также некоторые недостатки оочень сомнительно описаны
Некоторые? Давайте начнем прямо с пункта 1. Как называется пост? Почему инженеры тра-ля-ля. И в первом же пункте что… менеджеры не хотят терять контроль. И во втором тоже. Ну т.е. инжереров-то в тексте и нет, может кроме пары пунктов ближе к концу.
>в основном говоря про скрам
И путая вообще все со всем. Приплетая сюда же jira, например, которая вообще каким боком к agile?
vgglow
28.09.2021 15:33Нужны ли вообще переводные статьи на хабре (или шире - на подобных ресурсах, где требуются публикации для повышения каких-то возможностей)? Хмм... в вопросе ответ проклюнулся почему они появляются, а вопрос был в другом. Нужны ли в принципе переводные статьи? Если автор оригинала гуру в какой-то области и/или статья содержит свежие идеи/подходы, то да, иначе -- нет. ИМХО, естественно.
В любом случае перевод требует понимания смысла оригинала и изложение его в русской лексике. А когда слова вроде русские, а построение предложения не наше, тогда и возникает негатив.
Что касается Agile, то как и во всякой системе, что пришла с запада, в ней "нет души". Разве может у творческих людей (а разработчики - безусловно творческие люди, творцы) вызвать положительный отклик попытка формализовать их работу? Положительные комментарии скорее всего от менеджеров.
kantocoder Автор
29.09.2021 14:37Я сделал правки к статье, и добавил голосование, нужен agile или не нужен.
С вашей аргументацией против agile полностью согласен, и в отношении архитектуры, и в отношении standup'ов.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками
В waterfall'е тоже самое, только гимора микроменеджмента поменьше будет. Нет всей этой лабуды со стендапами, планированием, ретроспективой и далее по списку.
t0lik
28.09.2021 14:37"Проблемы, по которым инженеры презирают Agile" - совсем не по-русски, может "Причины"?
johnfound
28.09.2021 17:18+1Мне эта история с Agile напоминает история с коммунизмом – когда-то считали, что для коммунизма нужны какие-то специальные люди с коммунистическом мышлением. И этим аргументируют почему не получился коммунизм в соц странах – не сумели воспитать этих спец людей.
Так вот – грош цена такой
идеологииметодологии, для которой нужны специальных людей.
doozza
28.09.2021 18:03+3Уважаемая редакция хабра! Обратите внимание на ситуацию вокруг данного поста. Человек сделал не ахти какой перевод и активно отстаивал свою позицию Д'Артаньяна в обсуждении, за что сообщество единогласно заминусовало его комментарии, и заодно напихало в карму. За плохого качества пост и своеобразную точку зрения человека за одни сутки слили в необратимые минуса. Сдаётся мне, что он уже давно понял, чем недовольно сообщество, и урок усвоен — но карма же резиновая (особенно когда красная). Пожалуйста, введите rate limit кармы вида "пользователю за последние сутки уже поставили десять минусов в карму, наверное ему на сегодня хватит. Если всё ещё хотите поставить минус — приходите завтра".
«Виновных прогнать сквозь тысячу человек 12 раз. Слава Богу, смертной казни у нас не бывало, и не мне её вводить»
— Николай I https://ru.wikipedia.org/wiki/Шпицрутен
@Boomburum пынь
extempl
28.09.2021 19:01С одной стороны да, с другой - на этот случай предсмотрен единоразовый резет кармы.
doozza
28.09.2021 19:33+1Сейчас отрицательная карма — по сути карательный механизм за убеждения; считайте, концлагерь. Либо пользователь в этом концлагере остался навсегда, либо использует один шанс из него выйти (если ещё не отбило желание). Если пользователь решился-таки из него выйти, используя сброс кармы, он никогда не будет прежним; свою точку зрения он больше не станет высказывать из страха потерять ресурс окончательно, и превратится в тихого
овощанаблюдателя. Так сообщество само искореняет плюрализм мнений в дискуссиях — используя оценочный механизм в карательных целях.dimoff66
02.10.2021 14:41Есть выход - нарабатывай карму на статьях а потом пиши что хочешь в комментариях. Так видимо создается статейно ориентированное мышление. Мне лично лень писать статьи, я страдаю, что поделать.
kantocoder Автор
31.10.2021 23:08Резет кармы уже был, собственно для его осуществления я и опубликовал пару переводов про шустрые (ну, т.е. гибкие) методы разработки. Agile переводится как "юркий", "шустрый", но никак не "гибкий".
Al_Azif
28.09.2021 19:57+1Да ладно, зачем, "15 лет работало, и ещё 15 так же проработает", чо вы так заволновались-то?
Забавно, при этом, что первый же заплюсованный коммент предлагает вариант "Может стори пойнты?", видимо полагая, что "стори пойнты" - это адекватный перевод на русский, да-да.
И заодно подтверждая два тезиса:
1. карма на хабре - просто случайная отрыжка рандомов.
2. логика давно покинула сей сайт.
Лично от себя добавлю что обсуждение перевода двух слов на 16 страницах комментариев и закидывание автора говном - это позор для технического блога.
Вы все только что слили чуваку карму и он может теперь писать один раз в день.
Поздравляю, успехов вам с оптимизациями и держитесь там, ага.
PS: проще платник на медиуме завести, всё лучше чем этот натужный совковый концлагерь.extempl
29.09.2021 09:33+1А вы видимо не совсем понимаете, что дело не в сторипоинтах? Дело в отношении автора к читателям вида "я вот заморочился, сделал кое-какой перевод, читайте молча, внимайте и скажите спасибо что я вообще заморочился".
Если бы автор написал "да, я знаю, перевод дерьмо, пользовался гуглтранслейтом, спасибо за правки, сейчас всё поправлю" и "да, я подумал, что мой вариант перевода лучше, но я вижу что большинство так не думает, оставлю сторипоинтами" - ничего бы и не было.
Особенно это выглядит забавно с, цитирую из статьи
стендапов и уточнений бэклога, до ретроспектив — ритуалах «самосовершенствования», основанных на спринтах.
А вот "сторипоинты" не угодили.
Сторипоинт - это устоявшийся термин, нравится вам это или нет. Навязывать свой термин с такой подачей как у автора, сопровождая это кичиньем знания английского и родного русского (с переводом через гугл-транслейт, ага) - ну, эм… глупо просто.
victor_1212
29.09.2021 01:09+1>Мне эта история с Agile напоминает история с коммунизмом ... Так вот – грош цена такой
идеологииметодологии, для которой нужны специальных людей.мне понравился ваш комментарий, по-моему отлично,
сразу скажу перевода не читал (удобнее оригинал посмотреть), по поводу технологии рискну высказать очевидное соображение, что все зависит от проекта, и квалификации разработчиков, есть проекты где Agile уместен и эффективен, есть такие где неприменим (imho как и для любой технологии в программировании), также скажу, что мне больше интересны те где Agile не применим, но конечно понимаю и уважаю людей у кого вкусы другие
KoteMilote
29.09.2021 15:05Все описанные проблемы Agile упираются в плохой менеджмент, так может это не в методологии дело?
VolodjaT
Сюжетные точки? Так никто не говорит. Может стори пойнты?
Зачем переводить то о чем не имеете понятия? Или просто лень вычитывать гуглоперевод?
kantocoder Автор
story points переводится на русский как "сюжетные точки" или "сюжетные баллы". В России государственным языком является русский язык, им и следует пользоваться, а не кальками с английского. Ну, если в России живете.
PS. поправлю на "сюжетные баллы"
netricks
Story point будет сюжетной точкой, если мы говорим о книге или сценарии. Но тут то с какого лешего?
kantocoder Автор
По смыслу это "сюжетные баллы", ну или "баллы за историю", "баллы истории". Поправил "точки" на "баллы".
Наш национальный язык русский, а не анлийский, и тем более не английские кальки. Мне остается сожалеть, что те, кто учил вас agile, не удосужились сделать правильный перевод "story points"
netricks
Понятия не имею, что такое agile и с чем его едят. Я мимо пробегал. :)
Не все слова хорошо переводятся. Иногда есть хороший перевод и он приживается. А иногда нет, и тогда появляется стопятьсот переводов одного термина. В результате люди перестают друг друга понимать, и имеют скверный вид и плохое настроение. Оно нам надо? Чтобы этой печали в нашей жизни не находилось места, к таким перлам как "штангенциркуль" надо относиться спокойно.
iiopy4uk_mck
Но что характерно все знатоки автора поняли.
Metotron0
Я не понял, потому что не являюсь знатоком автора?
[/sarcasm]
kovriga25
Почему тогда "agile", а не "гибкая методология"? Как-то непоследовательно.
Akon32
"гибкий способ" тогда уж...
Color
Просто "гибкий".
эй, Петя, вы по гибкому работаете?
не, у нас водопад!
orthoxerox
По-русски будет "каскад"
scruff
А в соседнем отделе - толкотня и кабан
GarretThief
Почему одно слово "agile" переводится в два слова "гибкая методология"? Это же одно слово, пусть переводится в "ловкость".
Потому что они выбирают интеллект!
Tenebrius
Используй Силу!
mrise
"Ловкость" - это agility. Agile это скорее "Ловкий". И по смыслу подходит:
zuko3d
Если есть "баллы за историю", то будут и "баллы за математику"?
А если серьёзно, то некоторые термины намеренно не переводятся с иностранного языка. Вы же говорите "компьютер", а не ЭВМ; "мониторинг" вместо "система слежения"; "микроменеджмент" вместо "тщательное и подробное управление".
Если вам указывают на ошибку - надо её признать и исправить. Можно, конечно, и поспорить - но придётся привести серьёзные аргументы.
Silvestor
Так точно командир! Есть начать применять цикл "ДЛЯ" и условие "ЕСЛИ".
scruff
Сразу вспомнился мем https://www.youtube.com/watch?v=UEl5jSReBCo&t=10s
sunki
Прежде чем что-то переводить, хорошо бы сначала с русским языком разобраться. Калька это ровно то, чем занимаетесь вы, а именно – буквальный перевод без адаптации.
dopusteam
Услышал от коллеги примерно следующее:
'На daily meeting ты либо говоришь, что всё сделал, либо рассказываешь красивую историю, почему не сделал' - вот тут то нам и понадобятся сюжетные точки)
lam0x86
Даже если допустить, что в русском айти должна использоваться русская терминология (с чем я абсолютно не согласен), перевод "сюжетные баллы" или "сюжетные точки" просто отвратителен. Где сюжет? Мы кино снимаем или театральную постановку? Раз уж так хотите использовать русский язык, придумайте нормальный термин. Не обязательно переводить дословно.
kantocoder Автор
Английские кальки еще более отвратительны. Я владею английским практически на уровне как родного русского, но все эти "это сделало мой день" и прочии кальки меня просто бесят.
По смыслу это баллы, ну или очки.
netricks
Может пункты?
lam0x86
Я не про баллы или очки, а про слово «сюжет». Вы выше писали про «пользовательские истории» из джиры (опять же, не понятно, зачем добавлять «пользовательские» к «историям»?). А термин “story points” родился именно для оценки историй. Так при чем здесь сюжет?
kantocoder Автор
я добавил "(оригинал: story points)", чтобы было понятно, о чем речь. я подумаю как точнее и ближе по смыслу перевести "story points". В английском используют story, и по смыслу мне показалась что "сюжет" подойдет. Что делать, если лексика agile имеет отношение и литературе?
ogost
Раз уж так кичитесь своим знанием русского и английского языков, попрошу привести в порядок хотя бы эту часть текста:
На лицо гуглоперевод, вы не причесали ваш "перевод". Это очевидно даже мне, которому и русский, и английский не родные. Ну и про гибкую методологию вам уже напомнили.
mSnus
Это не баллы и не очки -- переводить так означает снова делать плохую
килькукальку с английского.Это оценка истории, а в баллах она измеряется , в поинтах или пунктах -- второй вопрос.
Переводите смысл, а не слова.
Hardened
A Story Point is a measurement unit that represents the amount of effort required to complete a task. Essentially, Story Points take the place of hours when estimating tasks in an Agile environment.
То есть все таки баллы или очки, раз единица измерения
mSnus
На русском можно говорить не так, как на английском, и будет более естественно. "Какие у тебя сегодня оценки в школе?", а не "какие баллы ты сегодня получил?"
А ваша цитата ещё и хорошо переводится на второй смысл: "оценка по времени".
То есть по русски мы озвучиваем "заголовок колонки", а они - "тип ячейки", как-то так ))
Akon32
story points - уровень котолампы
mSnus
story points - история указывает
pankraty
Хотел пройти мимо, но не смог сдержаться.
Это разве не калька? "Без предупреждения" было бы куда более по-русски.
dopusteam
"Ну уровне как родного русского", ну ясно понятно теперь
Bonio
И поэтому вы придумали очередной трешевый дословный перевод story point в "сюжетные точки"? Где логика?
VolodjaT
Да, так и представил как Вы рассказываете на собеседовании в какой нибудь EPAM о сюжетных точках. Хотел бы я видеть лицо интервьювера.
kantocoder Автор
Меня не пригласят, я уже указал в резюме что agile не рассматриваю. Проблема в том, что agile пихают везде, куда не поподя, а его применение ограниченно, как минимум. О чем и цикл статей-переводов.
BorisTheAnimal
Agile надо понимать и уметь интегрировать. Нужно понимать какую методологию/framework применять и где. Нельзя просто так взять и применить agile методологию и ожидать чуда. Нужно менять культуру.
Автор собственно и пишет об анти-паттернах. Не о том, что сам Agile плох или ограничен, а о том, что люди внедряющие его часто не понимают, что они делают. Чаще всего менеджмент пытается внедрить такой гибрид водопада(любят многие обманывать сами себя, мнимой видимостью долгосрочной предсказуемости), с церемониями (событиями) того же Scrum.
Кстати сам автор так же выбрал не сильно правильный термин в своей статье - пишет про Agile, но на деле ссылается по сути к Scrum(хотя бы в отношение тех же стори поинтов, т.к. в том же kanban flow совершенно другие метрики. А если мы возьмем тот же eXtreme Programming (XP), то там, без примесей других методологий/frameworks, вообще нет метрик предсказуемости. А XP это тоже Agile).
p.s. И если вы разработчик, и указали, что не рассматриваете "Agile" - почитайте про тот же eXtreme Programming.
usa_habro_user
Цель автора (i.e. Stefan Wolpers, а не @kantocoder, естественно), попромоутить "тихой сапой" самого себя, и свои продукты. Ну, а банальным мыслям о том, что Scrum в частности, а Agile в общем иногда (или даже обычно) применяют неправильно, не так и не с теми результатами - "сто лет в обед", но "воз и ныне будет там", пока это "хайпово, стильно и молодежно".
BorisTheAnimal
Я сначала подумал, что там какой-то newbie открыл для себя Agile и решил так раскрутится "хайпово" (любой PR, это PR), а потом посмотрел его профайл на linkedin и... много думал :)
Хотя, наверно со стороны, если глубоко не разбираешься, статья выглядит презентабельно.
MihasD
Чушь несете когда говорите про методологию, agile это прежде всего про взаимоотношение людей в команде, которая владеет кодом совместно и кровно заинтересована в результате и не столько в денежном выражении, сколько потому что им это интересно. А вы хотите это прищепнуть к корпоративной среде, живое к камню.
Наемный работник мало отличается от раба, разве что только тем что сам просится к своему рабовладельцу
Понимаю, сто слишком радикальное и спорное утверждение.
Но, по моему, в корпоративной среде agile работает только на новых проектах, когда разработчика дают много свободы, а потом все бюракратизируется
kantocoder Автор
Глянул. XP не без проблем, но по крайней мере в XP люди озаботились контролем качества через тесты. И оценкой рисков. И похоже это более продуманная методология.
Но опять же, где долгосрочное планирование? Нет долгосрочного планирования -- на выходе получаем известную субстанцию.
BorisTheAnimal
Подсказываю - в русскоязычных организациях story points если и переводят, то обычно либо в "пункты", либо, более вольно, в "попугаях". А переводить вот просто так, не зная темы - не стоит.
Areso
У нас просто говорили дни. Т е один сторипоинт это один день, и незачем было выдумывать новые сущности.
Shatun
ИМХО, но сторипоинты как дни рассматривать не очень правильно, хотя и возможно. Теряются плюсы самих сторипоинтов. Хотя многим людям так привычнее.
BorisTheAnimal
ну это уже мера измерения сторипоинтов. Дни, часы, числа фибоначчи, животные, фибоначчи т.д.. В целом, конечно, идея в том, что бы сторипоинты были абстрактными, что не создавать ощущения временных границ на разработчиков, как это происходит в случае использования дней и часов.
Areso
А в чем разница? Это как инвалидов назвать "люди с особенными потребностями".
Вот спринт, 2 недели. 14 календарных дней. 10 рабочих. 10 сторипоинтов.
В планнинге берешь себе задач на 5 сторипоинтов.
2 сторипоинта закладываешь на растянутые дейли, прочие церемонии (планнинг, груминг, ретро), и просто встречи.
3 сторипоинта закладываешь на техподдержку своего же (DevOps же) кода.
extempl
В том, что сторипоинты не дни? У вас они могли быть днями. У других это абстрактное понятие сложности, которое с днями не коррелирует.
Areso
Ну, пусть тогда будут абстрактные попугаи :)
Хотя измерять сложность задачи от 1 до NNN довольно странная идея. А вот время измеряют в секундах, минутах, часах, днях.
Так что сторипоинтами измеряют трудозатраты, а не сложность.
Shatun
А зачем на них сторипоинты закладывать? Вы в спринт делаете какое-то количество сторипоинтов фичей.
Areso
Потому что у кого-то не сходятся отчеты, если количество рабочих дней и количество сторипоинтов не бьется между собой.
Причина есть в статье:
Shatun
Потому что стори поинт и не обязн быть равен дню)
А тикеты на митинги я еще ниразу невидел если честно, хотя думал видел уже все извращения над скрамом.
Areso
Создается "резиновая" задача "Митинги XX-го спринта" и в неё списывают время (Log work), а перед началом спринта - дается оценка - ну, типо потратить на встречи не более двух рабочих дней :)
В конце спринта закрывается.
tmin10
Могут быть для списывания времени, когда требуется 100% отчёт о затраченных часах.
Hardened
Складывать пункты или точки, чтобы получить скорость, немного странно с точки зрения логики русского языка...
tommy_lee
Носители русского привыкли употреблять слово «сторипоинт» в данном контексте, значит это теперь тоже русский язык. Ждать одобрения термина оторванными от жизни академиками в каком-то замшелом институте - не обязательно
A1054
Я уважаю ваше право автора писать так, как вы считаете нужным.
Но моя точка зрения -- вы тут неправы. Не стоит догматически гнаться за словами из нужного языка. Лучше употреблять такие слова, к которым привыкли и на понимание которых уходит минимальное время. Если бы все привыкли к "сюжетным баллам" -- ОК. Но все привыкли к story points. Это словосочетание распознается очень быстро, а вот на то, чтобы сообразить, что такое "сюжетные баллы" уходит несколько секунд. Если это словосочетание стоит внутри длинного предложения или абзаца, то пока читатель осознает, что значит непривычное слово, у него из оперативной памяти может выветриться какое-нибудь придаточное предложение. И фразу, возможно. придется перечитывать. Т. е. читатель спотыкается.
Да, а какой там язык государственный, лично мне вообще неважно. Я не этатист. "Родной" звучало бы лучше. НО в мой родной русский вполне органично вплетены некоторые иностранные слова. В ваш, кстати, тоже, вы вдеь написали Agile.
ksbes
Прощу прошения, что влезаю, но вот для меня сторипоинтс (уж писать-то мы должны именно по-русски, когда говорим на родном языке) — это абсолютно пустое, ничего не говорящее слово. Просто набор букв.
А «сюжетные баллы», конечно, ерунда по виду и звучанию, но уже несут минимальный смысл (какие-то условные очки, которые начисляются в процессе каких-то сюжета(ов) и по которым, видимо потом что-то оценивают). Всё что здесь нужно для уточнения смысла — пояснить, что в данном контексте подразумевается под словом «сюжет».
Заимствовать слова — тоже надо правильно. Они должны быть как-то привязаны к тому или иному семантическому смыслу, предмету или действию.
Тот же «калькулятор» или «компьютер» — во-первых, уже были ранее заимствованы в бухгалтерии (это названия бухгалтерских специализаций — да в начале XX века компьютера можно было нанять за зарплату), а во-вторых то что этом словом называли стояло перед теми, кто этим словом пользовались (или просто изображалось на картинках в журналах газетах).
А вот ни слово «стори», ни слово «поинтс» — не были заимствованы ранее ни в каком смысле и не имеют никаких семантических первоисточников. Из прямое заимствование — некорректно, непонятно и отторгается свежим ухом. Нужен либо перевод (в данном случае — вряд ли — слишком коряво), либо вольная интерпретация, там «очки прогресса» или ещё как-то.
BorisTheAnimal
только вот вам от этого минимального смысла ни холодно ни жарко. Мы же не в "угадайку" играем. Если вы не в теме - вы в любом случае не поймете, а если вы хоть немного работаете в IT, то вы уже должны были привыкнуть работать с историями, сторипоинтами и т.п.. И увидим кряказябру в виде «сюжетные баллы» вы скорее впадате в ступор, чем от чего либо.
leon_nikitin
Здесь еще момент. Можно согласиться с заимствованием, когда аналогов в русском языке нет. Но, когда слышишь или читаешь такое: "Надо его захейтить, потому что он фактчекинг не заюзал и его стори - полный фэйк", становиться очень печально. Отчего это? Обезьянничание? Считается, что так человек показывает свою "крутость"? Или, просто, низкий культурный уровень и не уважение своей культуры?
doozza
У вас тут кальки, приберите, пожалуйста. В конце концов, в России живёте.
What Are Your Thoughts?
Каковы ваши мысли на этот счет? — калька. "А вы как считаете?", "А вы что думаете?"
a “good manager” by traditional standards is defined by
«хороший менеджер» по традиционным стандартам определяется тем, что — калька. "традиционно, «хороший менеджер»...", "как правило, считается, что «хороший менеджер»..."
Can you teach an old (management) dog, socialized in a command & control environment, new agile tricks?
Можете ли вы научить старого (менеджмент-) пса, прошедшего социализацию в среде команд и управления, новым трюкам Agile? — во-первых, калька.
Во-вторых, "you" не всегда означает буквальное "вы". Здесь оно обезличенное, примерно как "one". В-третьих, command & control - команда, да не та.
"Можно ли научить старого пса (менеджера), воспитанного в директивном стиле, новым agile-трюкам?"
What if it is about embracing learning, experimentation, and failure
Что, если речь идет о включении в себя обучения, экспериментов и неудач – эх, люблю утром после эджайла сесть в кресло, заварить чаёк и включить в себя обучение, эксперимент и неудачу (особенно неудачу, они лучше всего включаются).
"Что, если нужно стать открытым обучению, пробам и ошибкам..."
... and empowering teams to figure out the solution, but not to deliver it yourself.
... а также о предоставлении командам возможности найти решение, а не доставить его самостоятельно? – чувствуете силушку русского языка? "предоставлении командам возможности". А ещё появился новый конкурент на рынке доставки — теперь доставляют решения.
"... а также позволить командам искать решение самим, а не навязывать его."
The fundamental idea here is that [when teaching a concept, you have to tailor the style of teaching to where the learner is in their understanding] and that [progression follows a common pattern].
Здесь основная идея заключается в том, что при обучении концепции вы должны перекроить свой стиль преподования к тому, в каком понимании находится учащийся, и к тому, что прогресс следует общей схеме.
Не стиль перекроить к тому, что прогресс следует. А идея заключается в том, что нужно перекроить, и что прогресс следует общей схеме.
Не вас одного.
Это многое объясняет. Не уважаете читателей, получаете соответствующий результат. Кстати, это первый минус, который я поставил статье за несколько лет пребывания на хабре.
Спасибо, я уже вон как развлёкся, на три дня вперёд хватит.
lev_pashkovsky
Ток в android разработку не лезь пж, а то начнутся статьи про виды да деятельности.
fwiffo
Agile переводится на русский как "ловкий." Раз уж, как Вы говорите, в России гос. языком является русский язык, и им следует пользоваться, то используемые Вами слова "мониторинг", "паттерн", "микроменеджмент" и другие являются кальками с английского. Будьте добры, поправьте.
MihasD
термины лучше никогда не переводить, лучше для работы
leon_nikitin
Посыл про использование русского языка поддерживаю двумя рукам и двумя ногами. Все эти повсеместные англицизмы - что-то не здоровое.
serginfo2009
От создателей «надмозга» и «силиконовой долины».
KGeist
Это Гугл Транслейт с правками.
Google translate:
Автор:
zaiats_2k
Втф, автор? Почему вы заменили билет на тикет???
Areso
Вместо тикета должна быть задача.
kantocoder Автор
Я пользовался гугл-переводчиком как помощником, так где его перевод был хорошим, оставлял; там, где нет -- переводил сам. Гугл явно что-то подправил в своем переводчике, теперь перевод с английского на русский выходит на изумление хорошим.
Для развлечения можете перевести гугл-переводчиком оригинал, и посмотреть на разницу
invasy
Странно видеть
и о гуглопереводчике от одного человека.Советую ещё пару раз перечитать перевод или отдать корректору/переводчику.
KGeist
Гуглопереводчик, как и многие посредственные переводчики, любят переводить слово-в-слово. Но ведь перевод это не просто механическая замена слов. В русском языке мы строим предложения по-другому. Например, в английском языке транзитивные глаголы без объекта часто требуют it: нужно говорить "Do it!" вместо простого "Do!" И часто можно встретить в посредственных переводах калькирование этой особенности английского языка: "сделай это", "я вижу это", "я понимаю это", хотя по-русски так обычно не говорят (мы скорее скажем "сделай," "вижу", "понимаю" -- мы, кстати, ещё и местоимения опускаем). От таких переводов сразу разит чем-то дубовым -- вроде всё грамматически верно, но построение предложений... странное. И гуглопереводчик не исключение, т.к. он обучался на большом пласте посредственных переводов.
Я предпочитаю переводить следующим образом: прочитать фразу, понять смысл, переварить на абстрактном уровне, и затем пересказать так, как я бы сам рассказал своему другу/коллеге/и т.д. (в зависимости от контекста). Обычно в таком случае перевод получается довольно естественным. Я бы не стал основывать перевод на ГуглТранслейте, так как мы заведомо обрекаем перевод на определённую дубовость.
Imbecile
Сразу вспоминается Солженицын, "В круге первом":
Так что, к чему эти полумеры? Я бы с удовольствием прочитал статью на Хабре, полностью написанную на ЯПЯ.
MAXH0
А мне почему то АБС вспомнились и Амвросий Амбруазович Выбегалло с его лексикой. Очевидно разные книжки приводят к разным выводам...
gearbox
Статьи Мицгола вроде как с хабра не выпиливали.
MAXH0
А еще многие презирают Agile за любовь менеджеров говорить на русско-английском суржике.
Конечно, программисты в этом отношении имели иммунитет (сами таковы), но речь то идет в целом об инженерах и представителях других специальностей. Например, когда педагогам Кванториума проповедовали Agile на курсах, педагогам было ОЧЕНЬ неудобно переводить с суржика на русский. А там были и биологи, и инженеры, и программисты...
Agile безусловно ХОРОШАЯ методология. Но Agile-проповедники, зачастую, сектанты.