Комментарии 129
story points переводится на русский как "сюжетные точки" или "сюжетные баллы". В России государственным языком является русский язык, им и следует пользоваться, а не кальками с английского. Ну, если в России живете.
PS. поправлю на "сюжетные баллы"
Story point будет сюжетной точкой, если мы говорим о книге или сценарии. Но тут то с какого лешего?
По смыслу это "сюжетные баллы", ну или "баллы за историю", "баллы истории". Поправил "точки" на "баллы".
Наш национальный язык русский, а не анлийский, и тем более не английские кальки. Мне остается сожалеть, что те, кто учил вас agile, не удосужились сделать правильный перевод "story points"
Понятия не имею, что такое agile и с чем его едят. Я мимо пробегал. :)
Не все слова хорошо переводятся. Иногда есть хороший перевод и он приживается. А иногда нет, и тогда появляется стопятьсот переводов одного термина. В результате люди перестают друг друга понимать, и имеют скверный вид и плохое настроение. Оно нам надо? Чтобы этой печали в нашей жизни не находилось места, к таким перлам как "штангенциркуль" надо относиться спокойно.
Почему тогда "agile", а не "гибкая методология"? Как-то непоследовательно.
"гибкий способ" тогда уж...
Почему одно слово "agile" переводится в два слова "гибкая методология"? Это же одно слово, пусть переводится в "ловкость".
Почему инженеры презирают Ловкость?
Потому что они выбирают интеллект!
Используй Силу!
"Ловкость" - это agility. Agile это скорее "Ловкий". И по смыслу подходит:
- К нам в компанию снова пришёл Ловкий.
- Значит, премии не будет?
- Значит, премии не будет.
Если есть "баллы за историю", то будут и "баллы за математику"?
А если серьёзно, то некоторые термины намеренно не переводятся с иностранного языка. Вы же говорите "компьютер", а не ЭВМ; "мониторинг" вместо "система слежения"; "микроменеджмент" вместо "тщательное и подробное управление".
Если вам указывают на ошибку - надо её признать и исправить. Можно, конечно, и поспорить - но придётся привести серьёзные аргументы.
Так точно командир! Есть начать применять цикл "ДЛЯ" и условие "ЕСЛИ".
Сразу вспомнился мем https://www.youtube.com/watch?v=UEl5jSReBCo&t=10s
Прежде чем что-то переводить, хорошо бы сначала с русским языком разобраться. Калька это ровно то, чем занимаетесь вы, а именно – буквальный перевод без адаптации.
Услышал от коллеги примерно следующее:
'На daily meeting ты либо говоришь, что всё сделал, либо рассказываешь красивую историю, почему не сделал' - вот тут то нам и понадобятся сюжетные точки)
Даже если допустить, что в русском айти должна использоваться русская терминология (с чем я абсолютно не согласен), перевод "сюжетные баллы" или "сюжетные точки" просто отвратителен. Где сюжет? Мы кино снимаем или театральную постановку? Раз уж так хотите использовать русский язык, придумайте нормальный термин. Не обязательно переводить дословно.
Английские кальки еще более отвратительны. Я владею английским практически на уровне как родного русского, но все эти "это сделало мой день" и прочии кальки меня просто бесят.
По смыслу это баллы, ну или очки.
Может пункты?
Я не про баллы или очки, а про слово «сюжет». Вы выше писали про «пользовательские истории» из джиры (опять же, не понятно, зачем добавлять «пользовательские» к «историям»?). А термин “story points” родился именно для оценки историй. Так при чем здесь сюжет?
Раз уж так кичитесь своим знанием русского и английского языков, попрошу привести в порядок хотя бы эту часть текста:
Скорее, он начинается с применения «правил» на первом этапе, а затем удобно им придерживается, игнорируя вторым и третим этапами.
На лицо гуглоперевод, вы не причесали ваш "перевод". Это очевидно даже мне, которому и русский, и английский не родные. Ну и про гибкую методологию вам уже напомнили.
Это не баллы и не очки -- переводить так означает снова делать плохую кильку кальку с английского.
Это оценка истории, а в баллах она измеряется , в поинтах или пунктах -- второй вопрос.
Переводите смысл, а не слова.
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.
То есть все таки баллы или очки, раз единица измерения
На русском можно говорить не так, как на английском, и будет более естественно. "Какие у тебя сегодня оценки в школе?", а не "какие баллы ты сегодня получил?"
А ваша цитата ещё и хорошо переводится на второй смысл: "оценка по времени".
То есть по русски мы озвучиваем "заголовок колонки", а они - "тип ячейки", как-то так ))
Переводите смысл, а не слова.
story points - уровень котолампы
Хотел пройти мимо, но не смог сдержаться.
Что также является причиной перетасовки членов команды по короткому уведомлению.
Это разве не калька? "Без предупреждения" было бы куда более по-русски.
Я владею английским практически на уровне как родного русского
"Ну уровне как родного русского", ну ясно понятно теперь
но все эти "это сделало мой день" и прочии кальки меня просто бесят
И поэтому вы придумали очередной трешевый дословный перевод story point в "сюжетные точки"? Где логика?
Меня не пригласят, я уже указал в резюме что agile не рассматриваю. Проблема в том, что agile пихают везде, куда не поподя, а его применение ограниченно, как минимум. О чем и цикл статей-переводов.
Agile надо понимать и уметь интегрировать. Нужно понимать какую методологию/framework применять и где. Нельзя просто так взять и применить agile методологию и ожидать чуда. Нужно менять культуру.
Автор собственно и пишет об анти-паттернах. Не о том, что сам Agile плох или ограничен, а о том, что люди внедряющие его часто не понимают, что они делают. Чаще всего менеджмент пытается внедрить такой гибрид водопада(любят многие обманывать сами себя, мнимой видимостью долгосрочной предсказуемости), с церемониями (событиями) того же Scrum.
Кстати сам автор так же выбрал не сильно правильный термин в своей статье - пишет про Agile, но на деле ссылается по сути к Scrum(хотя бы в отношение тех же стори поинтов, т.к. в том же kanban flow совершенно другие метрики. А если мы возьмем тот же eXtreme Programming (XP), то там, без примесей других методологий/frameworks, вообще нет метрик предсказуемости. А XP это тоже Agile).
p.s. И если вы разработчик, и указали, что не рассматриваете "Agile" - почитайте про тот же eXtreme Programming.
Чушь несете когда говорите про методологию, agile это прежде всего про взаимоотношение людей в команде, которая владеет кодом совместно и кровно заинтересована в результате и не столько в денежном выражении, сколько потому что им это интересно. А вы хотите это прищепнуть к корпоративной среде, живое к камню.
Наемный работник мало отличается от раба, разве что только тем что сам просится к своему рабовладельцу
Понимаю, сто слишком радикальное и спорное утверждение.
Но, по моему, в корпоративной среде agile работает только на новых проектах, когда разработчика дают много свободы, а потом все бюракратизируется
Глянул. XP не без проблем, но по крайней мере в XP люди озаботились контролем качества через тесты. И оценкой рисков. И похоже это более продуманная методология.
Но опять же, где долгосрочное планирование? Нет долгосрочного планирования -- на выходе получаем известную субстанцию.
Подсказываю - в русскоязычных организациях story points если и переводят, то обычно либо в "пункты", либо, более вольно, в "попугаях". А переводить вот просто так, не зная темы - не стоит.
У нас просто говорили дни. Т е один сторипоинт это один день, и незачем было выдумывать новые сущности.
ИМХО, но сторипоинты как дни рассматривать не очень правильно, хотя и возможно. Теряются плюсы самих сторипоинтов. Хотя многим людям так привычнее.
ну это уже мера измерения сторипоинтов. Дни, часы, числа фибоначчи, животные, фибоначчи т.д.. В целом, конечно, идея в том, что бы сторипоинты были абстрактными, что не создавать ощущения временных границ на разработчиков, как это происходит в случае использования дней и часов.
А в чем разница? Это как инвалидов назвать "люди с особенными потребностями".
Вот спринт, 2 недели. 14 календарных дней. 10 рабочих. 10 сторипоинтов.
В планнинге берешь себе задач на 5 сторипоинтов.
2 сторипоинта закладываешь на растянутые дейли, прочие церемонии (планнинг, груминг, ретро), и просто встречи.
3 сторипоинта закладываешь на техподдержку своего же (DevOps же) кода.
В том, что сторипоинты не дни? У вас они могли быть днями. У других это абстрактное понятие сложности, которое с днями не коррелирует.
2 сторипоинта закладываешь на растянутые дейли, прочие церемонии (планнинг, груминг, ретро), и просто встречи.
А зачем на них сторипоинты закладывать? Вы в спринт делаете какое-то количество сторипоинтов фичей.
Потому что у кого-то не сходятся отчеты, если количество рабочих дней и количество сторипоинтов не бьется между собой.
Причина есть в статье:
Jira выступает как проявление вытекающих из этого бюрократических накладных расходов: заведите тикеты на все что возможно , чтобы сделать производительность каждого инженера видимой.
Потому что у кого-то не сходятся отчеты, если количество рабочих дней и количество сторипоинтов не бьется между собой.
Потому что стори поинт и не обязн быть равен дню)
А тикеты на митинги я еще ниразу невидел если честно, хотя думал видел уже все извращения над скрамом.
Создается "резиновая" задача "Митинги XX-го спринта" и в неё списывают время (Log work), а перед началом спринта - дается оценка - ну, типо потратить на встречи не более двух рабочих дней :)
В конце спринта закрывается.
Складывать пункты или точки, чтобы получить скорость, немного странно с точки зрения логики русского языка...
Носители русского привыкли употреблять слово «сторипоинт» в данном контексте, значит это теперь тоже русский язык. Ждать одобрения термина оторванными от жизни академиками в каком-то замшелом институте - не обязательно
Я уважаю ваше право автора писать так, как вы считаете нужным.
Но моя точка зрения -- вы тут неправы. Не стоит догматически гнаться за словами из нужного языка. Лучше употреблять такие слова, к которым привыкли и на понимание которых уходит минимальное время. Если бы все привыкли к "сюжетным баллам" -- ОК. Но все привыкли к story points. Это словосочетание распознается очень быстро, а вот на то, чтобы сообразить, что такое "сюжетные баллы" уходит несколько секунд. Если это словосочетание стоит внутри длинного предложения или абзаца, то пока читатель осознает, что значит непривычное слово, у него из оперативной памяти может выветриться какое-нибудь придаточное предложение. И фразу, возможно. придется перечитывать. Т. е. читатель спотыкается.
Да, а какой там язык государственный, лично мне вообще неважно. Я не этатист. "Родной" звучало бы лучше. НО в мой родной русский вполне органично вплетены некоторые иностранные слова. В ваш, кстати, тоже, вы вдеь написали Agile.
А «сюжетные баллы», конечно, ерунда по виду и звучанию, но уже несут минимальный смысл (какие-то условные очки, которые начисляются в процессе каких-то сюжета(ов) и по которым, видимо потом что-то оценивают). Всё что здесь нужно для уточнения смысла — пояснить, что в данном контексте подразумевается под словом «сюжет».
Заимствовать слова — тоже надо правильно. Они должны быть как-то привязаны к тому или иному семантическому смыслу, предмету или действию.
Тот же «калькулятор» или «компьютер» — во-первых, уже были ранее заимствованы в бухгалтерии (это названия бухгалтерских специализаций — да в начале XX века компьютера можно было нанять за зарплату), а во-вторых то что этом словом называли стояло перед теми, кто этим словом пользовались (или просто изображалось на картинках в журналах газетах).
А вот ни слово «стори», ни слово «поинтс» — не были заимствованы ранее ни в каком смысле и не имеют никаких семантических первоисточников. Из прямое заимствование — некорректно, непонятно и отторгается свежим ухом. Нужен либо перевод (в данном случае — вряд ли — слишком коряво), либо вольная интерпретация, там «очки прогресса» или ещё как-то.
уже несут минимальный смысл
только вот вам от этого минимального смысла ни холодно ни жарко. Мы же не в "угадайку" играем. Если вы не в теме - вы в любом случае не поймете, а если вы хоть немного работаете в IT, то вы уже должны были привыкнуть работать с историями, сторипоинтами и т.п.. И увидим кряказябру в виде «сюжетные баллы» вы скорее впадате в ступор, чем от чего либо.
Здесь еще момент. Можно согласиться с заимствованием, когда аналогов в русском языке нет. Но, когда слышишь или читаешь такое: "Надо его захейтить, потому что он фактчекинг не заюзал и его стори - полный фэйк", становиться очень печально. Отчего это? Обезьянничание? Считается, что так человек показывает свою "крутость"? Или, просто, низкий культурный уровень и не уважение своей культуры?
У вас тут кальки, приберите, пожалуйста. В конце концов, в России живёте.
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].
Здесь основная идея заключается в том, что при обучении концепции вы должны перекроить свой стиль преподования к тому, в каком понимании находится учащийся, и к тому, что прогресс следует общей схеме.
Не стиль перекроить к тому, что прогресс следует. А идея заключается в том, что нужно перекроить, и что прогресс следует общей схеме.
Английские кальки еще более отвратительны. Я владею английским практически на уровне как родного русского, но все эти "это сделало мой день" и прочии кальки меня просто бесят.
Не вас одного.
Я пользовался гугл-переводчиком как помощником, так где его перевод был хорошим, оставлял; там, где нет -- переводил сам. Гугл явно что-то подправил в своем переводчике, теперь перевод с английского на русский выходит на изумление хорошим.
Это многое объясняет. Не уважаете читателей, получаете соответствующий результат. Кстати, это первый минус, который я поставил статье за несколько лет пребывания на хабре.
Для развлечения можете перевести гугл-переводчиком оригинал, и посмотреть на разницу
Спасибо, я уже вон как развлёкся, на три дня вперёд хватит.
Ток в android разработку не лезь пж, а то начнутся статьи про виды да деятельности.
Agile переводится на русский как "ловкий." Раз уж, как Вы говорите, в России гос. языком является русский язык, и им следует пользоваться, то используемые Вами слова "мониторинг", "паттерн", "микроменеджмент" и другие являются кальками с английского. Будьте добры, поправьте.
термины лучше никогда не переводить, лучше для работы
Посыл про использование русского языка поддерживаю двумя рукам и двумя ногами. Все эти повсеместные англицизмы - что-то не здоровое.
От создателей «надмозга» и «силиконовой долины».
Это Гугл Транслейт с правками.
Google translate:
Важнейшими показателями Agile являются сюжетные точки и скорость, а Jira выступает как проявление вытекающих из этого бюрократических накладных расходов: имейте билет на все и вся, чтобы сделать работу каждого инженера заметной.
Автор:
Важнейшими показателями Agile являются сюжетные баллы (оригинал: story points) и скорость, а Jira выступает как проявление вытекающих из этого бюрократических накладных расходов: имейте тикет на все и вся, чтобы сделать производительность каждого инженера видимой.
Втф, автор? Почему вы заменили билет на тикет???
Я пользовался гугл-переводчиком как помощником, так где его перевод был хорошим, оставлял; там, где нет -- переводил сам. Гугл явно что-то подправил в своем переводчике, теперь перевод с английского на русский выходит на изумление хорошим.
Для развлечения можете перевести гугл-переводчиком оригинал, и посмотреть на разницу
Я владею английским практически на уровне как родного русскогои
теперь перевод с английского на русский выходит на изумление хорошимо гуглопереводчике от одного человека.
Советую ещё пару раз перечитать перевод или отдать корректору/переводчику.
Гуглопереводчик, как и многие посредственные переводчики, любят переводить слово-в-слово. Но ведь перевод это не просто механическая замена слов. В русском языке мы строим предложения по-другому. Например, в английском языке транзитивные глаголы без объекта часто требуют it: нужно говорить "Do it!" вместо простого "Do!" И часто можно встретить в посредственных переводах калькирование этой особенности английского языка: "сделай это", "я вижу это", "я понимаю это", хотя по-русски так обычно не говорят (мы скорее скажем "сделай," "вижу", "понимаю" -- мы, кстати, ещё и местоимения опускаем). От таких переводов сразу разит чем-то дубовым -- вроде всё грамматически верно, но построение предложений... странное. И гуглопереводчик не исключение, т.к. он обучался на большом пласте посредственных переводов.
Я предпочитаю переводить следующим образом: прочитать фразу, понять смысл, переварить на абстрактном уровне, и затем пересказать так, как я бы сам рассказал своему другу/коллеге/и т.д. (в зависимости от контекста). Обычно в таком случае перевод получается довольно естественным. Я бы не стал основывать перевод на ГуглТранслейте, так как мы заведомо обрекаем перевод на определённую дубовость.
Сразу вспоминается Солженицын, "В круге первом":
Разговаривает на Языке Предельной Ясности, то есть, не употребляя иностранных слов (его изобретение): вместо "сферы" - "ошария", "скептицизм" - "усугубленное неверие", "святотатство" - "святохулышчество", "идеалы" - "светлообразы" и т. п."
Так что, к чему эти полумеры? Я бы с удовольствием прочитал статью на Хабре, полностью написанную на ЯПЯ.
А еще многие презирают Agile за любовь менеджеров говорить на русско-английском суржике.
Конечно, программисты в этом отношении имели иммунитет (сами таковы), но речь то идет в целом об инженерах и представителях других специальностей. Например, когда педагогам Кванториума проповедовали Agile на курсах, педагогам было ОЧЕНЬ неудобно переводить с суржика на русский. А там были и биологи, и инженеры, и программисты...
Agile безусловно ХОРОШАЯ методология. Но Agile-проповедники, зачастую, сектанты.
Нельзя сказать, что этот метод полностью игнорирует принцип Щю-Ха-Ри, используемый для изучения новой техники:
Здесь основная идея заключается в том, что при обучении концепции вы должны перекроить свой стиль преподования к тому, в каком понимании находится учащийся, и к тому, что прогресс следует общей схеме. На ранних этапах обучения основное внимание уделяется имитации конкретных шагов, затем акцент смещается на понимание принципов и, наконец, на самостоятельную инновацию.
Забавно :) Только вот пару дней назад своему ученику писал:
Стадия 1. Научиться делать так, как сказано.
Стадия 2. Понять почему это работает и почему это правильно
Стадия 3. Научиться это менять и делать по-другому.
Если ты не готов в Стадию 1, то ничего не получится. Я устану отвечать на разрозненные вопросы, которые никак не укладываются в общую канву.
Оказывается, это ShuHaRi))
До сегодняшнего дня я и сам не знал про Щю-Ха-Ри.
Я вот про Сюхари знал, но Щю-Ха-Ри это что-то новенькое...
А я давно уже знал. Но простите, называл Су-Ха-Ри (и запомнить лучше)
На стадии 2 можно только Уверовать, но никак не понять.
Именно что можно и нужно. Речь сейчас не о проектах типа "Подтянул джуна на совместную разработку убийцы гугла". Речь о простых базовых решениях. Так вот на первой стадии ученик еще вообще ничего не понимает. Ему даешь тестовые уроки, он читает в них теорию, кое-как подставляет решение, чтобы тест прошел успешно, и часто вообще не понимает что тут к чему (просто получается из задачи и требований вычленить что надо сделать). Но переходит к другому уроку и прошлый забывает сразу.
На второй стадии он хотя бы может уже разобрать решение, понять что здесь происходит (здесь массивы создаются, здесь сввойства объекту присываиваются и т.п. и т.п.). Он уже начинает понимать почему при работе со строками одни методы используются, а на числах другие. Но пока что он просто это понимает. Когда ему говоришь "А сделай так, чтобы результат был тот же, но использовать совсем другие методы". Вот тут он может вообще ничего не придумать. И это нормально.
Ну в про третий уровень можно и не говорить, там свобода творчества.
И все это я не просто так говорю. Я занимаюсь обучением программистов и все это довольно четко вижу на практике.
Я не верю во все эти гибкие методологии. Я верю в менеджмент, как смысл жизни, как подход к любой проблеме тебя окружающей. Менеджерами не становятся ими рождаются. В эталонном менеджере помимо хватки, разумности, рассудительности и дальнозоркости должны присутствовать такие качества как несгибаемость и конечно же харизма. Ну нельзя брать на работу менеджера с несколькими сертификатами о прохождении курсов, парочкой проектов. За долгие годы общения с МП при первом собеседовании, либо встрече определяю грамотный специалист передо мной или просто зубрилка. Внешний вид, уверенность, чёткость фраз, горящие глаза. Вот это всё делает проект успешным.
Agile, Scrum и тому подобные методологии лишь подспорье хорошему руководителю. Сам периодически перечитываю литературу, что-то черпаю для себя. Но слепо верить во всё что написано это глупо. Тикеты можно исключить, спринты сделать более рациональными и гибкими по времени. В общем согласен с автором. В погоне за идеальным подходом многие из нас стали заложниками этих манифестов. Хотя в советском союзе было всё тоже самое, только называлось по другому. А люди строили БАМ, воздвигали здания и перемещали целые ЦЕХА. Просто должна душа гореть и желание бить ключом. Остальное либо приложится либо придёт само.
Менеджеры бывают разные и по стилю и по темпераменту и по навыкам, по скоупу ответственности, по энергетике. И я не согласен, что менеджерами рождаются - это чушь. Проводя параллель, любой спортсмен скажет, что талант и тренировки это 10% и 90%.
Ой, ну бросьте, так и про программистов можно говорить. И что 95% посредственностей теперь уволить и в дворники перевести.
>дальнозоркости
Дальновидности, наверно?
В эталонном менеджере помимо хватки, разумности, рассудительности и дальнозоркости должны
… а еще, он непременно должен уметь летать!
Те же самые обычные люди там, совершенно ни чем не лучше и не умнее остальных :) Все с теми же комплексами, затыками и иллюзиями.
А в скраме нет такой роли "менеджер". Хоть я и прекрасно понимаю, про что вы, однако считаю, что скрам и вытягивает команды, в которых нет хороших менеджеров. Просто следуйте процессу как умеете и что-нибудь более-менее хорошее получится.
А вот в waterfall даже если вы крутой менеджер, у вас всё равно будут пропущенные дэдлайны и чэндж реквесты.
Не знал до сегодняшнего дня что инженеры презирают Agile. Я не презираю, среди моих знакомых, насколько я знаю, тоже никто презрительно об Agile не отзывался. Нормально делай, нормально будет.
Проблема не в Agile или другой технологии, а когнитивных искажениях и эгоизме участников процесса.
"Отцы основатели" Agile забыли законы Мерфи.
"Если что-то может быть сделано не правильно, это будет сделано не правильно."
Точно так же и с Agile.
Его понимают не правильно, не потому что "люди плохие", а потому что Agile (принципы Agile) спроектирован плохо.
Ну или "Благими намерениями выстелена дорого в Ад".
Так что Agile идет в "правильном" направлении. :-)
А вы поинтересуйтесь, кем являются отцы-основатели agile и сколько из них разработчиков.
А так да, Вы правы. Есть такой принцип дизайна интерфейсов: интерфейс нужно делать таким, чтобы им было легко пользоваться правильно, и трудно -- неправильно. А agile'ом в точности до наоборот.
На самом деле проблема глубже. Похоже что ВСЕ гибкие методологии (и XP, и RAD) не могут быть использованы для создания сложных продуктов и для систем, критических к безопасности. А поскольку все больше и больше инфраструктуры переходит на IT, аgile как минимум не нужен, а как максимум -- просто опасен.
С помощью Agile некоторые "эффективные менеджеры" пытаются управлять, и чем хуже его менеджерские качества тем упорнее он будет натсаивать на "праведности" agile. Зачастую средний состав прогибает людей под методику, а не наоборот методику под людей. Agile - это всего лишь один из инструментов, который можно перестроить под свою специфику и пользоваться им. А можно гвозди забивать, как это делают некоторые.
Story points - может "этапы задачи", не?
Если один этап принять равным одному дню...
Но тогда уж 'подходов' :)
5 подходов и я справлюсь! - звучит, как утверждение сильного программиста.
Это как естественные и суррогатные ключи в БД.
Зачем вводить искусственные единицы измерения, если имеются естественные и понятные всем дни, часы, недели? Не понимаю и никогда не пойму.
Конечно же при условии, что команда научилась как-то в этих стори поинтах оценивать задачи более-менее одинаково.
опять же - кто платит "индустрии Agile консалтинга" ? Программисты\инженеры ?
Увы, поток денег идет от тех, кто хочет снизить свои риски, поэтому даже немного странно удивляться, что представленный сам себе, он "переупаковывает философию, изначально ориентированную человека и на технологии, в стандартизированную, всепогодную методологию по снижению проектных рисков"
Всё по классике: "если вам что-то дают бесплатно, то товар - это вы".
А чтобы такого не случалось, команде придется заплатить своими усилиями по освоению + подгонке по месту + внедрению и поддержке, чтобы инструмент служил команде, а не вышестоящему менеджменту...
А все эти методики — водопады, ГОСТЫ, agile нужны именно чтобы «утилизировать» не самый лучший человеческий материал, которого на несколько порядков больше, чем «супермегапрофи». Т.е. исполнители в них изначально должны закладываться не самого лучшего «качества» (т.е. не особо заинтересованными, преследующими эгоистичные интересы и т.д.). Любая методика организации всегда будет в большинстве своём исполняться в режиме «карго-культа». Армейский принцип.
Вопрос только насколько эффективно этот «карго-культ» ведёт к желаемому результату и ведёт ли вообще.
Проблема этой статьи в том, что человек тупо перевёл с английского какую-то чушь, не разобравшись. Думал рейтинга и кармы нафармить с минимальными трудозатратами - а в итоге сел в лужу.
Для разработки ПО, аджайл - одна из самых лучших МЕТОДОЛОГИЙ разработке. То, что не все могут в её реализацию - это другой вопрос:
Менеджеры продавливают свою оценку трудозатрат.
"Решения по-прежнему принимаются людьми, которые не разбираются в технологиях. "
Многие проблемы вообще надуманы.
Да взять те же деили митинги - раньше меня бесило на них время тратить, когда я поработал тимлидом - понял, что без них гораздо сложнее работать.
Думаю, что последнее обновление Скрам Гайда постаралось учесть многие моменты из данной статьи.
ИМХО (на правах человека 5 лет пытающегося разобраться с Agile).
Agile божественно великолепен, но он основан на ценностях. Если команда не в полной мере разделяет ценности, то начинаются проблемы и карго-культ. Попытки навязать ценности на основании повторения ритуалов и терминологии карго-культа, возникает унылое сектанство. Демонстрацией этого процесса служит холивар развернувшийся в первом же комменте.
Итак, @kantocoder был приглашен НЛО буквально вчера. И ему за две статьи критикующих Agile уже слили карму в минуса. Agile не догма, а руководство к действию. Он не может быть свободен от критики.
Agile божественно великолепен, но он основан на ценностях. Если команда не в полной мере разделяет ценности
Но тут возникает вопрос, насколько такие команды часто встречаются. Не исчезают ли они по мере роста компании. И способствует ли Agile сохранению мотивации или наоборот.
Опять же сугубое ИМХО, но вы совершенно правы. По мере роста они исчезают. Agile это уровень стартапа. Для больших возможно поток создания ценности Тойоты и прочий кайдзен, не знаю...
Мой огородик, который я копаю по Agile мал и ни как не связан с крупными компаниями. Я пытаюсь внести в образование Agile так, чтобы не учить плохому и не множить карго-культов. Надеюсь, что не очень быстро, но получается. Главное понять, что Agile это не о листочках приклеенных скотчем к доске...
I. Контроль
Менеджмент среднего звена не желает отказываться от контроля…
И где тут инженеры, которые ненавидят?
Поэтому на мой взгляд, все что в посте написано — по большей части просто натягивание совы на глобус.
Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Да, agile - Это плохая архитектура, это недостаток времени на вдумчивую разработку, это вечная гонка под минимальные стандарты и отсутствие творчества, так как часы на творчество менеджеры не предусмотрели, и с заказчиком что-то что предлагается командой, обсуждают они неохотно. Это бессмысленные дейли, где люди с постными физиономиями вынуждены выслушивать кучу информации, которая им не нужна, будучи вырванными из естественного внутреннего ритма разработки.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками. И это посредничество пользы разработке не приносит.
Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Негатив к идее и негатив к гуглтранслейту с неуклюжей попыткой изобрести свои "сюжетные точки" - разные вещи. Тем более голосовать могут все, а менять карму - нет.
Как так получается, что большинство комментариев негативны по отношению к статье, автору слита карма, а голосование поддерживает его точку зрения? Чудеса.
Минусы неставил, но могу сказать почему мне статья ненравится.
Автор везде пишет про agile, но непонимает что это такое, в основном говоря про скрам. Например пункты про стори поинты, спринты, ретро-откуда они взялись в аджайле? Это характерно для скрама как вида аджайла, но в статье про скрам вообще ничего нету. Я например больше люблю канбан, без всяких стори поинтов и спринтов-согласитесь это довольно распростарненная практика. И это вполне аджайл.
Также некоторые недостатки оочень сомнительно описаны. Например про тикеты в джире-"имейте тикет на все и вся" -откуда это вообще взялось, почему в аджайле(или скраме, т.к. непонятно про что именно пишет автор) тикетов больше, с чем сравнивается и почему это плохо? Не могу сказать что в вотрефоле например тикетов меньше, причем у них более сложный жизненный цикл обычно.
Пригнувшись, и очень тихо. А Канбан-метод он как бы не аджайл...
Некоторые? Давайте начнем прямо с пункта 1. Как называется пост? Почему инженеры тра-ля-ля. И в первом же пункте что… менеджеры не хотят терять контроль. И во втором тоже. Ну т.е. инжереров-то в тексте и нет, может кроме пары пунктов ближе к концу.
>в основном говоря про скрам
И путая вообще все со всем. Приплетая сюда же jira, например, которая вообще каким боком к agile?
Нужны ли вообще переводные статьи на хабре (или шире - на подобных ресурсах, где требуются публикации для повышения каких-то возможностей)? Хмм... в вопросе ответ проклюнулся почему они появляются, а вопрос был в другом. Нужны ли в принципе переводные статьи? Если автор оригинала гуру в какой-то области и/или статья содержит свежие идеи/подходы, то да, иначе -- нет. ИМХО, естественно.
В любом случае перевод требует понимания смысла оригинала и изложение его в русской лексике. А когда слова вроде русские, а построение предложения не наше, тогда и возникает негатив.
Что касается Agile, то как и во всякой системе, что пришла с запада, в ней "нет души". Разве может у творческих людей (а разработчики - безусловно творческие люди, творцы) вызвать положительный отклик попытка формализовать их работу? Положительные комментарии скорее всего от менеджеров.
Я сделал правки к статье, и добавил голосование, нужен agile или не нужен.
С вашей аргументацией против agile полностью согласен, и в отношении архитектуры, и в отношении standup'ов.
В статье указана основная слабость agile - главными становятся менеджеры, фактически посредники между заказчиком и разработчиками
В waterfall'е тоже самое, только гимора микроменеджмента поменьше будет. Нет всей этой лабуды со стендапами, планированием, ретроспективой и далее по списку.
"Проблемы, по которым инженеры презирают Agile" - совсем не по-русски, может "Причины"?
Мне эта история с Agile напоминает история с коммунизмом – когда-то считали, что для коммунизма нужны какие-то специальные люди с коммунистическом мышлением. И этим аргументируют почему не получился коммунизм в соц странах – не сумели воспитать этих спец людей.
Так вот – грош цена такой идеологии методологии, для которой нужны специальных людей.
Уважаемая редакция хабра! Обратите внимание на ситуацию вокруг данного поста. Человек сделал не ахти какой перевод и активно отстаивал свою позицию Д'Артаньяна в обсуждении, за что сообщество единогласно заминусовало его комментарии, и заодно напихало в карму. За плохого качества пост и своеобразную точку зрения человека за одни сутки слили в необратимые минуса. Сдаётся мне, что он уже давно понял, чем недовольно сообщество, и урок усвоен — но карма же резиновая (особенно когда красная). Пожалуйста, введите rate limit кармы вида "пользователю за последние сутки уже поставили десять минусов в карму, наверное ему на сегодня хватит. Если всё ещё хотите поставить минус — приходите завтра".
«Виновных прогнать сквозь тысячу человек 12 раз. Слава Богу, смертной казни у нас не бывало, и не мне её вводить»
— Николай I https://ru.wikipedia.org/wiki/Шпицрутен
@Boomburum пынь
С одной стороны да, с другой - на этот случай предсмотрен единоразовый резет кармы.
Сейчас отрицательная карма — по сути карательный механизм за убеждения; считайте, концлагерь. Либо пользователь в этом концлагере остался навсегда, либо использует один шанс из него выйти (если ещё не отбило желание). Если пользователь решился-таки из него выйти, используя сброс кармы, он никогда не будет прежним; свою точку зрения он больше не станет высказывать из страха потерять ресурс окончательно, и превратится в тихого овоща наблюдателя. Так сообщество само искореняет плюрализм мнений в дискуссиях — используя оценочный механизм в карательных целях.
Резет кармы уже был, собственно для его осуществления я и опубликовал пару переводов про шустрые (ну, т.е. гибкие) методы разработки. Agile переводится как "юркий", "шустрый", но никак не "гибкий".
Да ладно, зачем, "15 лет работало, и ещё 15 так же проработает", чо вы так заволновались-то?
Забавно, при этом, что первый же заплюсованный коммент предлагает вариант "Может стори пойнты?", видимо полагая, что "стори пойнты" - это адекватный перевод на русский, да-да.
И заодно подтверждая два тезиса:
1. карма на хабре - просто случайная отрыжка рандомов.
2. логика давно покинула сей сайт.
Лично от себя добавлю что обсуждение перевода двух слов на 16 страницах комментариев и закидывание автора говном - это позор для технического блога.
Вы все только что слили чуваку карму и он может теперь писать один раз в день.
Поздравляю, успехов вам с оптимизациями и держитесь там, ага.
PS: проще платник на медиуме завести, всё лучше чем этот натужный совковый концлагерь.
А вы видимо не совсем понимаете, что дело не в сторипоинтах? Дело в отношении автора к читателям вида "я вот заморочился, сделал кое-какой перевод, читайте молча, внимайте и скажите спасибо что я вообще заморочился".
Если бы автор написал "да, я знаю, перевод дерьмо, пользовался гуглтранслейтом, спасибо за правки, сейчас всё поправлю" и "да, я подумал, что мой вариант перевода лучше, но я вижу что большинство так не думает, оставлю сторипоинтами" - ничего бы и не было.
Особенно это выглядит забавно с, цитирую из статьи
стендапов и уточнений бэклога, до ретроспектив — ритуалах «самосовершенствования», основанных на спринтах.
А вот "сторипоинты" не угодили.
Сторипоинт - это устоявшийся термин, нравится вам это или нет. Навязывать свой термин с такой подачей как у автора, сопровождая это кичиньем знания английского и родного русского (с переводом через гугл-транслейт, ага) - ну, эм… глупо просто.
>Мне эта история с Agile напоминает история с коммунизмом ... Так вот – грош цена такой идеологии методологии, для которой нужны специальных людей.
мне понравился ваш комментарий, по-моему отлично,
сразу скажу перевода не читал (удобнее оригинал посмотреть), по поводу технологии рискну высказать очевидное соображение, что все зависит от проекта, и квалификации разработчиков, есть проекты где Agile уместен и эффективен, есть такие где неприменим (imho как и для любой технологии в программировании), также скажу, что мне больше интересны те где Agile не применим, но конечно понимаю и уважаю людей у кого вкусы другие
Все описанные проблемы Agile упираются в плохой менеджмент, так может это не в методологии дело?
Почему инженеры презирают Agile