LINUX.ORG.RU

Jira

 ,


0

5

Довелось некоторое время пользоваться этим чудом техники. Я считаю, что Jira является лучшим доказательством того, что все эти новомодные методологии разработки не работают. Ну, то есть работают, и производят редкостное говнище.

Я имею в виду тот факт, что в нем не существует удобного вида в принципе, есть только неудобные и очень неудобные. Боже упаси вам в задачу вставить скриншот — вас все проклянут. Нужно только отдельным вложением, чтобы открывалось popup-ом, потому что абсолютно все прокрутки в Jira представляют собой катастрофу, особенно те, которые отображаются там, где на самом деле прокручивать нечего (привет горизонтальной прокрутке истории на 1700 пикселях ширины окна).

В системе есть такая замечательная штука, как организация задачи в доски, но вот беда — организации самих досок нет. Менеджер организовал вашей команде доску, и теперь он должен бегать за вам и убеждаться, что вы видите смотрите туда, куда он думает что вы смотрите.

Я бы вспомнил еще претензию по поводу отсутствия возможности отменять изменения задачи, которые вносятся в онную одним кликом, но проблему можно решить отправив SMS на короткий номер приобрести расширение, которое добавляет отмену изменений: https://marketplace.atlassian.com/apps/1220176/action-undo-for-jira?hosting=s...

Я вот и не пойму, то ли это такой хитрый план по вытягиванию денег, как у докера, мол, «хотите работать нормально — покупайте наши расширения», то ли все-таки эти проблемы до конца не решаются, а сама Jira писалась как отчет о проведенной работе и не подразумевалась для применения конечным пользователем? Поясните, кто поопытнее.

★★★★

Последнее исправление: alpha (всего исправлений: 1)

Ответ на: комментарий от byko3y

Нет, дело не в одной жаве, а в «бинго!».

Ну т.е. ты все равно считаешь жаву базвордом?

REST — это и есть HTTP. Это не надстройка над HTTP или под HTTP, это и есть HTTP, один в один, полностью соблюдающая этот протокол и не выходящая за его пределы, причем, весь этот функционал был доступен в браузерах с самого начала. Если быть совсем точным, то HTTP — это реализация принципов REST. Нельзя взаимодействовать с сервером по REST, потому что REST не является протоколом. В самом HTTP протоколе нет ни одного упоминания REST, там есть только HTTP, ведь это протокол HTTP. Потому серьезные ребята используют для взаимодействия с сервером HTTP, а маркетологи-впариватели и разведенные ими лохи — REST.

Это какой-то поток сознания, если честно. REST дает унификацию и предсказуемость. Это не протокол (с чего ты вообще взялся это опровергать?), это «архитектурный стиль».

Я не сторонник монолитов, я сторонник оправданной архитектуры. Не оправданной модными тенденциями в пузыренадувании, а оправданной задачами, которыми софтина должна выполнять.

Пока у меня крепнет ощущение, что ты сторонник изобретения велосипедов. Чем плохо распространение среди толп средней руки программистов идей SOA?

Это указывает на отсутствие контроля и организации разработки. Что, на самом деле, и есть те самые новомодные методы организации разработки, когда менеджер дупля не стрельнет, что в его проекте происходит и куда он идет, его максимальный горизонт — 2 недели, а там хоть солнце не свети, при этом исполнители тоже не понимают, что делают, потому что их горизонт — это несколько задач в трекере. Здесь, конечно же, применяется Agile/Kanban/Scrum, чтобы ни у менеджеров, ни у исполнителей не было ни одной свободной минуты разобраться в проекте, а только писать ежесекундно новые фичи.

Бред. Возможно, подкрепленный плохим опытом использования аджайла на хреновых проектах с тупым менеджментом.

Примерно так же делают разрабы Atlassian, и, вполне возможно, кто-то из них даже пытался достучаться до руководства по поводу необходимости исправления тех или иных проблем.

Бизнес хочет фичи. Если у PM/PO не хватает навыков довести до бизнеса необходимость разгребания бэклога - это не проблемы аджайла, это проблемы PM/PO.

И что за оркестратор?

Мы его не опенсорсили. Если кратко - это подобие кубернетеса, заточенное под наши нужды.

Компания. производящая низкокачественный товар или оказывающая низкокачественные услуги, может выживать на рынке за счет своего имени, лояльности клиентов, или тупо удачному маркетингу. Но нужно смотреть не на положительную прибыль, а на упущенную. В теории ведь фирма могла быть абсолютным монополистом на рынке, если бы подтянула свои слабые стороны.

А могла бы и сдохнуть, потратив тонны времени на вылизывание продукта, пока конкуренты клепают полусырые фичи одну за другой.

В свое время Nokia была близка к монопольному положению, она неплохо чувствовала себя на фоне лютейшего кризиса управления и огромного перерасхода ресурсов. В итоге проблемы перевесили былые заслуги и потопили компанию. Ты бы и в 2010 году говорил, что бизнес же устраивает выкатывать старое говно или новое сырое говно, прибыль есть, так о чем же париться? Но проходит три года, и компания становится банкротом.

Не очень вижу связь между проблемами аджайла и хренового управления корпорацией. Но кстати, Нокия как раз сидела на попе ровно и онанировала на симбиан, когда нужно было делать фичи. В итоге эпл с гуглом сожрали рынок убогими по функциональности и забагованными айосью и андроидом.

Страница задачи — это центральное звено всей Jira

Это морда центрального звена. На бэке там все неплохо, вообще-то. А морду переписать недолго.

Вообще, у меня возникает ощущение, что тебе либо лет 20 и еще не отпустил юношеский максимализм, либо за полтос и ты скучаешь по атмосфере НИИ, где можно было месяцами продумывать софтину на бумажке.

leave ★★★★★
()
Ответ на: комментарий от leave

REST дает унификацию и предсказуемость. Это не протокол (с чего ты вообще взялся это опровергать?), это «архитектурный стиль».

Унификацию и предсказуемость даёт, например, XML-RPC (когда приходится думать и соглашаться о том, что будет течь внутри; формальности и единообразия больше, в отличие от от балды нарисованных эндпоинтов), в случае с кучкой рест-ошмётков об унификации API внутри HTTP будут думать в последнюю очередь.

anonymous
()
Ответ на: комментарий от leave

«архитектурный стиль»

Архитектурным он становится, когда его продумывают, чего на практике не случается.

anonymous
()
Ответ на: комментарий от leave

Ну т.е. ты все равно считаешь жаву базвордом?

В 2002 году — да. Сейчас она уходит на второй план, сейчас модно нода-бигдата-клауд-ИИ-блокчейн.

REST дает унификацию и предсказуемость. Это не протокол (с чего ты вообще взялся это опровергать?), это «архитектурный стиль»

К архитектурному стилю нельзя сделать запрос, для него нельзя написать клиент, архитектурный стиль нельзя обслужить на сервере, и его нельзя проапгрейдить но новую версию. Слово REST используется именно в значении «HTTP», и только в нем. Но если ты скажешь «HTTP API», то лошара подумает «тьфу, там это же древний HTTP, не могли что-то посовременнее сделать?». И тогда лошаре придумывают новое словосочетание «REST API» — ну совсем другое дело, REST API нам очень нужен.

Пока у меня крепнет ощущение, что ты сторонник изобретения велосипедов. Чем плохо распространение среди толп средней руки программистов идей SOA?

SOA — это эффективный способ решить очень простую задачу при помощи двух десятков сотрудников и горы софта. Подавляющему большинству людей SOA не нужно и никогда не понадобится, потому что это большие накладные расходы, которые ничем не оправданы. И здесь Atlassian довольно грамотно сделало ставку на лошар, которые идут за модой, а не за квалифицированным решением.

Возможно, подкрепленный плохим опытом использования аджайла на хреновых проектах с тупым менеджментом

И у тебя есть примеры не хреновых проектов с умным менеджментом, использующих Agile? Я таких не знаю.

PM/PO

Нет таких букв в этом слове. Крутите барабан.

А могла бы и сдохнуть, потратив тонны времени на вылизывание продукта, пока конкуренты клепают полусырые фичи одну за другой
Не очень вижу связь между проблемами аджайла и хренового управления корпорацией. Но кстати, Нокия как раз сидела на попе ровно и онанировала на симбиан, когда нужно было делать фичи. В итоге эпл с гуглом сожрали рынок убогими по функциональности и забагованными айосью и андроидом

Там много чего было, там были и старые неразвивающиеся продукты, были и новые забагованные сервисы. Я здесь ни разу не выступаю на какой-то крайней стороне, я лишь пишу про хронический недостаток внимания к качеству в современной экономике, вызванный повальным говноедством.

Это морда центрального звена. На бэке там все неплохо, вообще-то. А морду переписать недолго

А я о чем пишу? Морду переписать недолго, но они не могут этого сделать, потому что у них плохо организована разработка.

у меня возникает ощущение, что тебе либо лет 20 и еще не отпустил юношеский максимализм, либо за полтос и ты скучаешь по атмосфере НИИ, где можно было месяцами продумывать софтину на бумажке

Оба варианта мимо.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

я лишь пишу про хронический недостаток внимания к качеству в современной экономике

Во. А что, собственно, такое качество?

Nervous ★★★★★
()
Ответ на: комментарий от leave

Вообще, у меня возникает ощущение, что тебе либо лет 20 и еще не отпустил юношеский максимализм, либо за полтос и ты скучаешь по атмосфере НИИ, где можно было месяцами продумывать софтину на бумажке.

У меня складывается впечатление, что человек очень хочет работать по четкому, неизменяемому ТЗ по той простой причине, что никогда так не работал.

Кстати, что интересно, но четкого и неизменяемого ТЗ с детальным проектом даже на стройке не бывает.

CaveRat ★★
()
Ответ на: комментарий от byko3y

В 2002 году — да

Atlassian сделала ставку на новую технологию и не прогадала. Так же, как BEA (в 2002 у них уже куплен работающий jrockit) и IBM.

К архитектурному стилю нельзя сделать запрос, для него нельзя написать клиент, архитектурный стиль нельзя обслужить на сервере, и его нельзя проапгрейдить но новую версию.

Жира собирала базворды уже в то время: Java, REST, SOA

Сначала у меня появилось неясное ощущение, что ты споришь сам с собой.

Слово REST используется именно в значении «HTTP», и только в нем. Но если ты скажешь «HTTP API», то лошара подумает «тьфу, там это же древний HTTP, не могли что-то посовременнее сделать?». И тогда лошаре придумывают новое словосочетание «REST API» — ну совсем другое дело, REST API нам очень нужен.

А потом я утвердился в этой мысли.

SOA — это эффективный способ решить очень простую задачу при помощи двух десятков сотрудников и горы софта. Подавляющему большинству людей SOA не нужно и никогда не понадобится, потому что это большие накладные расходы, которые ничем не оправданы.

Что ты написал в своей жизни сложнее хеловорлда? Подавляющему большинству людей, которые пишут клиент-серверное ПО, SOA нужно постоянно. И еще больше оно нужно заказчиками этого ПО, потому что за SOA ты платишь один раз на старте, а за монолиты ты платишь постоянно. Ты не можешь изменить структуру БД монолита, не остановив полностью все приложение.

И у тебя есть примеры не хреновых проектов с умным менеджментом, использующих Agile? Я таких не знаю.

CardSuite. World of Tanks. Plussa.com. Mintdata. Во всех этих проектах разработка ведется по аджайлу (скрам; у плюссы, когда я там работал, был lean).

Нет таких букв в этом слове.

В твоем маня-мирке не бывает проектных менеджеров? Ты точно программист?

Я здесь ни разу не выступаю на какой-то крайней стороне, я лишь пишу про хронический недостаток внимания к качеству в современной экономике, вызванный повальным говноедством.

А, так ты идеалист. Сразу бы и сказал. Капиталу срать на абстрактное «качество». Заказчику нужно, чтобы проект приносил бабки, за вылизывание кода до состояния кошачьей мошонки он не собирается платить, потому что принцип Парето.

А я о чем пишу? Морду переписать недолго, но они не могут этого сделать, потому что у них плохо организована разработка.

Разработка у них организована хорошо. И морду они переписать могут. Но не хотят сейчас тратить на это ресурсы, потому что потому. Ни ты, ни я не видели их роадмапа.

leave ★★★★★
()
Ответ на: комментарий от CaveRat

Я на 100% уверен, что он с коммерческой разработкой рядом не стоял. Единственная отрасль, где будут писать так, как он хочет - это aerospace. Ну, возможно, кое-где в медицине.

leave ★★★★★
()
Ответ на: комментарий от leave

ты можешь сколько угодно переубеждать этого поехавшего, но меня достало обсуждение проблемы, которой нет. морда-шморда, прокрутка-шмокрутка. этой прокрутки уже несколько лет как нет, баг закопали вместе со старым интерфейсом, а других проблем он так и не сумел сформулировать за весь тред.

goper48265
()
Ответ на: комментарий от leave

Ну, я-то тоже с коммерческой разработкой рядом не стоял (я вообще не программист), но так, как он хочет, не бывает вообще нигде, и дело не только в погоне за прибылью, но и в том, что окружающий мир, негодяй такой, меняется. И, вместе с ним, меняются требования к создаваемой системе.

PS Используем jira для проектов по внедрению всего - софта, железа и процессов, вся семья жива, рекомендуем.

CaveRat ★★
()
Ответ на: комментарий от leave

CardSuite. World of Tanks. Plussa.com. Mintdata. Во всех этих проектах разработка ведется по аджайлу (скрам; у плюссы, когда я там работал, был lean)

Мне тяжело что-то ответить по остальным пунктам, но оригинальный World of Tanks не разрабатывался по Agile, по этому методу сейчас работают над World of Tanks Blitz для игрофонов, и если ты поинтересуешься у игроков, то узнаешь, что по их мнению проект катится в говно. Связано ли это со вводом Agile, или с уходом старого ведущего разраба, или с чем-то еще — мы вряд ли узнаем.

Подавляющему большинству людей, которые пишут клиент-серверное ПО, SOA нужно постоянно

Ты путаешь клиент-сервер и сервис-ориентированную архитектуру. Сервис-ориентированная архитектура подразумевает расчленение единого проекта на сервисы, взаимодействующие между собой по сетевым протоколам. Да. можно клиент-сервер с натяжкой назвать сервис-ориентированной архитектурой, и даже два компа, которые качают друг у друга порнушку через торренты, можно назвать сервис-ориентированной архитектурой, но это вопрос того, когда еще «мало», а когда уже «много». На фоне SOA принято считать, что в торрентах и клиент-сервере SOA мало, потому что взаимодействие ведут законченные узлы, а не зависимые сервисы.

В твоем маня-мирке не бывает проектных менеджеров? Ты точно программист?

В моем манямирке нет мудацих сокращений.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

но оригинальный World of Tanks не разрабатывался по Agile, по этому методу сейчас работают над World of Tanks Blitz для игрофонов

Я там работаю, не надо мне рассказывать, как мы разрабатываем продукты. Да, изначально в танках был типичный вотерфолл и рабочий день по 12 часов в атмосфере стартапа. Последние несколько лет в танках аджайл. 90% игровой обвязки (а это ~200 сервисов) пилится по скраму.

и если ты поинтересуешься у игроков, то узнаешь, что по их мнению проект катится в говно

вообще никакой связи с методологией разработки. Проблемы танков вызваны отделом баланса, который слушает отдел монетизации. Хомячки донатят, когда могут гнуть, поэтому игра пилится под хомячков. Sad but true.

Ты путаешь клиент-сервер и сервис-ориентированную архитектуру. Сервис-ориентированная архитектура подразумевает расчленение единого проекта на сервисы, взаимодействующие между собой по сетевым протоколам. Да. можно клиент-сервер с натяжкой назвать сервис-ориентированной архитектурой…

Нет, не путаю. Я специально привел вырожденный пример. Твой клиент может стучаться в монолитный кусок непойми чего или в прослойку, которая будет заниматься диспетчеризацией запросов, аутентифицировать тебя через другой сервис и делать длинные фоновые операции силами третьего приложения.

Черт побери, даже те же самые танки под капотом не запускают один жирный бинарь. https://habr.com/ru/company/wargaming/blog/272265/ (первая картинка).

В моем манямирке нет мудацих сокращений.

Покажи мне компанию-разработчика ПО, в которой project manager’а не называют PM.

leave ★★★★★
()
Ответ на: комментарий от leave

но оригинальный World of Tanks не разрабатывался по Agile, по этому методу сейчас работают над World of Tanks Blitz для игрофонов

Я там работаю, не надо мне рассказывать, как мы разрабатываем продукты. Да, изначально в танках был типичный вотерфолл и рабочий день по 12 часов в атмосфере стартапа. Последние несколько лет в танках аджайл. 90% игровой обвязки (а это ~200 сервисов) пилится по скрам

И, где я неправ? Разрабатывали бы сразу по аджайлу — мы бы про танки так и не узнали. Agile — это, по сути, формализация отсутствия организации. Я не говорю о том, что отсутствие организации — это плохо. Это удобно и эффективно для некоторых проектов, коротких, маленьких, которые делаются на месяц-два, и потом выкидываются или переписываются.

Черт побери, даже те же самые танки под капотом не запускают один жирный бинарь. https://habr.com/ru/company/wargaming/blog/272265/ (первая картинка)

Во-первых, WoT дорос до тех самых масштабов, в которых использование сервисов начинает быть оправданным. Во-вторых. пикл не бывает быстрым и эффективным. Вообще. Совсем. Те оптимизации, которые описаны в статье — это днище в стиле agile/scrum (странно, 2015 год?), типа «вот я два дня потратил на написание и тестирование, а теперь отстаньте от меня», без настоящего анализа проблемы и поиска решения, на которые понадобилось бы заметно больше времени, но и дало бы намного больше результата в виде снижения объема передаваемых данных и использования ресурсов процессора. Это сумели сделать, например, в YouTube, где есть высококвалифицированные питонщики.

Покажи мне компанию-разработчика ПО, в которой project manager’а не называют PM

В компаниях, где говорят про русски и не делают вид бурной деятельности. Особенно когда говорят с людьми, которые не являются частью коллектива.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Agile — это, по сути, формализация отсутствия организации

Эм, ШТА???

Это удобно и эффективно для некоторых проектов, коротких, маленьких, которые делаются на месяц-два, и потом выкидываются или переписываются.

Я даже не знаю… А как ты отнесешься, если я тебе скажу, что любой большой проект состоит из небольших задач, которые и занимают месяц-два, или даже меньше?

В компаниях, где говорят про русски и не делают вид бурной деятельности…

использую сокращение РП. Хотя, сокращение PM тоже используют.

CaveRat ★★
()
Ответ на: комментарий от byko3y

И, где я неправ? Разрабатывали бы сразу по аджайлу — мы бы про танки так и не узнали. Agile — это, по сути, формализация отсутствия организации. Я не говорю о том, что отсутствие организации — это плохо. Это удобно и эффективно для некоторых проектов, коротких, маленьких, которые делаются на месяц-два, и потом выкидываются или переписываются.

Опять какие-то дикие маня-фантазии.

Во-первых, WoT дорос до тех самых масштабов, в которых использование сервисов начинает быть оправданным

Во-первых, это изначальная архитектура.

Во-вторых. пикл не бывает быстрым и эффективным. Вообще. Совсем. Те оптимизации, которые описаны в статье — это днище в стиле agile/scrum (странно, 2015 год?), типа «вот я два дня потратил на написание и тестирование, а теперь отстаньте от меня», без настоящего анализа проблемы и поиска решения, на которые понадобилось бы заметно больше времени, но и дало бы намного больше результата в виде снижения объема передаваемых данных и использования ресурсов процессора.

Я показал тебе одну долбаную картинку, но ты решил блеснуть знаниями? Статья про события 2013 года. Суть проблемы глубоко в сишном ядре, для ее фикса надо переписать весь bigworld.

Это сумели сделать, например, в YouTube, где есть высококвалифицированные питонщики.

Ты близко не представляешь себе ни наши проблемы перфоманса, ни ютубовские. И уровень девелоперов тоже не представляешь. Впрочем, это все оффтопик.

В компаниях, где говорят про русски

Таких компаний нет. Айтишка бывает только на аглийском. Смирись.

и не делают вид бурной деятельности. Особенно когда говорят с людьми, которые не являются частью коллектива.

Ну т.е. ты тут третий день усираешься, доказывая убогость аджайла, при этом ни единого дня не проработав по этому самому аджайлу. И, как я уже говорил, ты не имеешь вообще никакого отношения к коммерческой разработке ПО, потому что любой сраный джун знает, что такое PM в контексте разработки.

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 1)
Ответ на: комментарий от CaveRat

Я даже не знаю… А как ты отнесешься, если я тебе скажу, что любой большой проект состоит из небольших задач, которые и занимают месяц-два, или даже меньше?

Я отвечу, что это абстракция уровня «человек состоит из кусков мяса». То есть, нельзя просто собрать в кучу небольшие задачи и получить большой проект.

Agile — это, по сути, формализация отсутствия организации

Эм, ШТА???

Я описывал здесь или в соседнем треде моем треде, что одна из важнейших задача менеджера — это перевод между языками заказчика, руководителя, и исполнителя. Чем лучше выполнене перевод, чем точнее ясны требования, и чем яснее заказчик видит, что получится в итоге, тем больше менеджер оправдал свою зряплату. Если же программист слепо выполняет короткие задачи заказчика или менеджера, не обращая внимания на архитектуру, особенности реализации, технические возможности, если требования формируются со слов заказчика, увидевшего сырую версию и не способного оценить важность и сложность тех или иных недоработок ранее чем через несколько месяцев эксплуатации системы (когда уже будет поздно и переделывать систему будет дорого), когда команда фокусируется на ничего не значащих рюшечках, которые можно два раза в неделю менять, но проще всего было этим заниматься в последний месяц, а при этом действительно серьезные проблемы откладываются снова и снова, потому что их не получится решить до следующего релиза, который через неделю — это классический Agile. С этой стороны также очевидно, что это бардак.

использую сокращение РП. Хотя, сокращение PM тоже используют

Вы можете договориться между собой о любом сокращении. Более того, вы можете договориться со мной о любых сокращениях, но мне пока что никто никаких кодов дешифрования не сообщал, так что шифровки просьба отправлять в свой штаб. Для ЛЛ. Чтб бл збс.

byko3y ★★★★
() автор топика
Ответ на: комментарий от leave

Во-первых, WoT дорос до тех самых масштабов, в которых использование сервисов начинает быть оправданным

Во-первых, это изначальная архитектура

Ну что я опять не так сказал? Дорос, а мог и не дорасти. Сколько проектов умерло, имея замечательную модульную архитектуру, в которую было ввалено кучу денег? А вот Path of Exile, например, имеет минимальное разделение на модули: один монолит у них называется «instance», который держит все ресурсы игры (пямять экономится за счет форка) и является самим игровым миром, куда кидает всех игроков в пати, и второй законченный сервис хранит все данные об игроках, их вещах, выполняет авторизацию. Да, со временем возникли второстепенные сервисы, на которые перекладывали задачи с крупных серверов, но они создавались по мере нужны, а не в расчете на будущее, которое никогда не наступит.

Краткий итог: круто разделять независимые узлы (a.k.a. трекер и качающие друг у друга порнуху клиенты), не круто разделять единую систему на связанные сервисы.

Таких компаний нет. Айтишка бывает только на аглийском. Смирись

I'm fine with it, but if you gonna talk to me in english than you should really do it and not just pretend like you do. However, I'd like to remind you we are sitting in the russian-speaking board where russian language is being used, so you should try to respect other users.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Я отвечу, что это абстракция уровня «человек состоит из кусков мяса». То есть, нельзя просто собрать в кучу небольшие задачи и получить большой проект.

Ты знаешь про такое хитрое дзюцу, как «декомпозиция задачи»?

Я описывал здесь или в соседнем треде моем треде, что одна из важнейших задача менеджера — это перевод между языками заказчика, руководителя, и исполнителя. Чем лучше выполнене перевод, чем точнее ясны требования, и чем яснее заказчик видит, что получится в итоге, тем больше менеджер оправдал свою зряплату.

Какого менеджера? Линейного? Проектного? Сейлз? Аккаунт?

Если же программист слепо выполняет короткие задачи заказчика или менеджера, не обращая внимания на архитектуру, особенности реализации, технические возможности, если требования формируются со слов заказчика, увидевшего сырую версию и не способного оценить важность и сложность тех или иных недоработок ранее чем через несколько месяцев эксплуатации системы (когда уже будет поздно и переделывать систему будет дорого), когда команда фокусируется на ничего не значащих рюшечках, которые можно два раза в неделю менять, но проще всего было этим заниматься в последний месяц, а при этом действительно серьезные проблемы откладываются снова и снова, потому что их не получится решить до следующего релиза, который через неделю — это классический Agile. С этой стороны также очевидно, что это бардак.

Я честно прочитал весь этот текст, и могу не менее честно сказать тебе, что то, что ты описал - это не Agile.

Вы можете договориться между собой о любом сокращении. Более того, вы можете договориться со мной о любых сокращениях, но мне пока что никто никаких кодов дешифрования не сообщал, так что шифровки просьба отправлять в свой штаб. Для ЛЛ. Чтб бл збс.

Ты меня сейчас очень сильно удивил, потому, что я еще не встречал людей, которые работали бы в проектных компаниях (имею ввиду работающих для внешних заказчиков), и которые бы не знали сокращения РП/PM (руководитель проекта/project manager).

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Ты знаешь про такое хитрое дзюцу, как «декомпозиция задачи»?

Да, только потом все равно нужно композицировать как-то ее обратно. Это и есть то самое, что по Agile не делается в принципе. Некие индусы из моей конторы примерно сейчас эту простую истину и познают, сложным путем, но мне кажется, что их необучаемость в итоге окажет верх и потопит проект.

Какого менеджера? Линейного? Проектного? Сейлз? Аккаунт?

Это что-то по Задорнову, типа «менеджер по минетингу». Нет, менеджер — это человек, управдяющий людьми. По русски это будет «руководитель». Формальные статусы разные руководители могут иметь разные, но функции у них всех довольно близкие. Примерно как кодер на PHP может поправить скрипты на питоне, но этого не сможет сделать девочка-дизайнер.

Я честно прочитал весь этот текст, и могу не менее честно сказать тебе, что то, что ты описал - это не Agile

Какова же ваша версия реальности?

Ты меня сейчас очень сильно удивил, потому, что я еще не встречал людей, которые работали бы в проектных компаниях (имею ввиду работающих для внешних заказчиков), и которые бы не знали сокращения РП/PM (руководитель проекта/project manager)

PM знаю даже я, но мне кажется, что ты не представляешь, какие есть дичайшие названия должностей в забугорных фирмах — я не намерен даже пытаться разобраться, что пытался сказать очередной руководитель, когда называл себя каким-нибудь «Business Development Executive».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Нет, менеджер не следует переводить как «руководитель». Ни в русском языке, ни в английском. Более близко: управляющий. А управляющим можно назвать кого угодно.

anonymous
()
Ответ на: комментарий от anonymous

Нет, менеджер не следует переводить как «руководитель». Ни в русском языке, ни в английском. Более близко: управляющий. А управляющим можно назвать кого угодно

Пф-ф-ф:

https://ru.wikipedia.org/wiki/Менеджер

Ме́неджер (англ. manager, происхождение от manage «управлять») руководи́тель, управля́ющий — начальник, занятый управлением процессами и персоналом на определённом участке предприятия, организации.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Не очень понимаю, что ты сказать хотел. Просто вот смотри, например:

https://en.wikipedia.org/wiki/Account_manager

Назвать этого человека управляющим - да, окей. Назвать его руководителем - это далеко не всегда валидно. У руководителя должны быть люди (ненавижу эту формулировки) в подчинении. А в указанном случае это вовсе не гарантируется. Как и в случае, например, менеджера по закупкам или рекламе.

anonymous
()
Ответ на: комментарий от anonymous

https://en.wikipedia.org/wiki/Account_manager
Назвать этого человека управляющим - да, окей. Назвать его руководителем - это далеко не всегда валидно. У руководителя должны быть люди (ненавижу эту формулировки) в подчинении. А в указанном случае это вовсе не гарантируется. Как и в случае, например, менеджера по закупкам или рекламе.

А в сфере маркетинга людям ЧСВ не занимать, я изо дня на день жду появления Менеджера Доброты и Успеха.

https://en.wikipedia.org/wiki/Account_executive
https://en.wikipedia.org/wiki/Advertising_account_executive
https://en.wikipedia.org/wiki/Brand_management
https://en.wikipedia.org/wiki/Chief_brand_officer

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Так там у всех такие титулы.

  • chief information officer
  • chief information security officer

А самые упоротые чсвшники, которых я видел, как раз прогеры.

anonymous
()
Ответ на: комментарий от anonymous

А самые упоротые чсвшники, которых я видел, как раз прогеры

В нашей параше я вообще не слышал про какие-то градации у прогеров, например. Обычно если прогер светит своим званием, то либо его так назвал руководитель, либо это не прогер, а какой-то щегол-ЧСВ-шник, который выдает себя за прогера, вроде егора бугаенко.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Ну я не про это. А про то, как человек себя в жизни ведёт. Здесь на форуме есть индивиды, у которых чсв больше чем у всего списка форбс.

anonymous
()
Ответ на: комментарий от byko3y

Да, только потом все равно нужно композицировать как-то ее обратно.

Что ты несешь, какая композиция обратно? Если у тебя по результатам выполнения небольших пакетов работ проект не заработал - ты неправильно его декомпозировал, ну или не завершил работы по отдельным пакетам.

Это и есть то самое, что по Agile не делается в принципе.

С учетом твоего предыдущего перла я пока не буду это комментировать, ОК?

Некие индусы из моей конторы примерно сейчас эту простую истину и познают, сложным путем, но мне кажется, что их необучаемость в итоге окажет верх и потопит проект.

И при чем тут твои индусы?

Это что-то по Задорнову, типа «менеджер по минетингу». Нет, менеджер — это человек, управдяющий людьми. По русски это будет «руководитель». Формальные статусы разные руководители могут иметь разные, но функции у них всех довольно близкие.

Вот ни разу не угадал. Менеджер совершенно не обязательно управляет людьми. В первую очередь менеджер управляет процессом, управление людьми - это только одна часть, которая в явно виде может и отсутствовать.

Не, я согласен, можно уйти в философию и сказать, что любой процесс делают люди, и без управления людьми нет управления процессами, и это будет правда. Но по штатке тот же РП вполне может и не иметь ни одного подчиненного, и успешно вести к победе огромные толпы.

Какова же ваша версия реальности?

В моей реальности манифест agile воспринимается как набор рекомендаций по организации работы над проектом. Пришлось его немного переосмыслить (хотя бы по той причине, что мы не пишем софт), но суть постарались сохранить.

Только дело в том, что любые управленческие рекомендации, лучшие практики, методики и прочие умные мысли надо перед применением переосмыслять, натягивая на тот глобус, который есть под рукой. Вот вообще любые.

PM знаю даже я, но мне кажется, что ты не представляешь, какие есть дичайшие названия должностей в забугорных фирмах — я не намерен даже пытаться разобраться, что пытался сказать очередной руководитель, когда называл себя каким-нибудь «Business Development Executive».

Странно, а я так примерно сразу понял, что такое этот BDE, что он делает и зачем он нужен.

CaveRat ★★
()
Ответ на: комментарий от byko3y

Краткий итог: круто разделять независимые узлы (a.k.a. трекер и качающие друг у друга порнуху клиенты), не круто разделять единую систему на связанные сервисы.

4.2

Выдирать потом из «единой системы» модули ОЧЕНЬ больно и дорого. Плюс масштабирование получается сильно дороже, потому что ресурсов монолит жрет в N раз больше, чем модуль.

I’m fine with it, but if you gonna talk to me in english than you should really do it and not just pretend like you do. However, I’d like to remind you we are sitting in the russian-speaking board where russian language is being used, so you should try to respect other users.

Ни малейшего понятия, почему ты смешиваешь неформальное общение на лоре с профессиональной средой. Project Manager это общепринятое обозначение. Если ты с ним не согласен то предлагаю тебе начать писать на 1с - там везде будет милая твоему сердцу кириллица.

Алсо, давай посчитаем количество относительно свежих заимствований и английских слов в твоей же речи:

Сколько проектов умерло, имея замечательную модульную архитектуру, в которую было ввалено кучу денег? А вот Path of Exile, например, имеет минимальное разделение на модули: один монолит у них называется «instance», который держит все ресурсы игры (пямять экономится за счет форка) и является самим игровым миром, куда кидает всех игроков в пати, и второй законченный сервис хранит все данные об игроках, их вещах, выполняет авторизацию. Да, со временем возникли второстепенные сервисы, на которые перекладывали задачи с крупных серверов, но они создавались по мере нужны, а не в расчете на будущее, которое никогда не наступит.

Переписывай.

leave ★★★★★
()
Ответ на: комментарий от CaveRat

Он даже бизнес-аналитика ни разу в жизни в глаза не видел, и свято верит, что хотелки заказчика транслируются в разработку силами PM’а. 100% что его максимум это какой-то бодишоп на 30 человек за $15/час на внешку.

leave ★★★★★
()
Ответ на: комментарий от leave

К стыду своему, должен признать, что бизнес-аналитика я тоже в глаза не видел. Хотелки заказчика (и все сопутствующие требования) у нас добывает главный инженер проекта от направления.

А РП вообще может в это не погружаться, особенно, если проект комплексный и включает в себя множество направлений, от бетона до ERP.

Просто у меня иногда реально гореть начинает, когда я слышу/читаю про то, что такой-то подход - шлак, отстой, смузихлебство и порождение тупого энтерпрайза. Начинаешь потом разговаривать, и выясняется, что автор подходов и методик этих не читал, а если читал - то не понял, и превратил в карго-культ, забыв адаптировать под окружающую реальность. Даже в обдолбаном PMBoK от PMI (он реально обдолбаный, я его читал) чуть ли не на первой страницей большим кеглем написано - АДАПТИРУЙТЕ ПОД СВОЮ ОРГАНИЗАЦИЮ И КОНКРЕТНЫЙ ПРОЕКТ, УЧИТЫВАЙТЕ ОСОБЕННОСТИ ВАШЕЙ РАБОТЫ! Нет, блэт, попробуем в небольшой проект на 1-3 направления и полгода срока пихать полный комплект всех процессов, а потом устраивать истерики, что PMBoK - говно.

И с Agile та же фигня, на самом деле.

Извините, пригорело.

PS Я нахожусь где-то между РП и исполнителями в проектной структуре, и вижу эту ситуацию с обеих сторон.

CaveRat ★★
()
Последнее исправление: CaveRat (всего исправлений: 1)
Ответ на: комментарий от CaveRat

Сперва какой-нибудь оболтус будет ныть три часа, нафига нам mission statement, что за фигня, давайте просто работать, потом пройдет два месяца, и этот же оболтус будет ходить и ныть, что он нифига не понимает, что он делает, и зачем это надо, и опять какой-то кал вместо работы.

PS Еще раз извините, это лютый оффтоп, но реально пригорело. Можно удалить, на самом деле.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

Дайте огнетушитель в этот тред %)

anonymous
()
Ответ на: комментарий от CaveRat

что за фигня, давайте просто работать, потом пройдет два месяца, и этот же оболтус будет ходить и ныть, что он нифига не понимает, что он делает, и зачем это надо

Тысячу плюсов этому участнику.

Из той же серии: «зачем нам писать code style для проекта, всё же очевидно», и через месяц «почему я провожу все свое время в спорах о том сколько пробелов ставить в отступах».

Или «Зачем отписывать по статусу задачи в тикет, это бюрократия!» и одновременно «достали менеджеры которые все время пингуют с вопросами по статусу задачи».

Или «зачем проводить ретроспективу, что за менеджерские игрища?» и «я сто раз ныл про проблему X, а меня никто не слушает»

И т.д. и т.п.

alpha ★★★★★
()
Ответ на: комментарий от CaveRat

Что ты несешь, какая композиция обратно? Если у тебя по результатам выполнения небольших пакетов работ проект не заработал - ты неправильно его декомпозировал, ну или не завершил работы по отдельным пакетам

Если у приложение есть архитектура, ТЗ, то это уже как минимум итеративная разработка, а не Agile. Agile вообще предписывает не иметь заранее определенной архитектуры, и вы не должны знать, что и как вы будете собирать из отдельных модулей, а решать этот вопрос непосредственно в процессе релизов — эти условия у тебя не выполняются, а значит ты описываешь не Agile. Еще и ко мне претензии предъявляешь.

В моей реальности манифест agile воспринимается как набор рекомендаций по организации работы над проектом. Пришлось его немного переосмыслить (хотя бы по той причине, что мы не пишем софт), но суть постарались сохранить

Нет, вам пришлось отказаться от Agile, потому что Agile вам не подходит.

byko3y ★★★★
() автор топика
Ответ на: комментарий от leave

Плюс масштабирование получается сильно дороже, потому что ресурсов монолит жрет в N раз больше, чем модуль

Что? Еще и меня в 4.2 обвиняет. Расскажи мне, как сервисы по сети, пусть и loopback-у, передают данные быстрее прямой записи в оперативную память, а я послушаю.

Project Manager это общепринятое обозначение

Да. А вот PO/PM, как и EKL/MN — не являются общепринятыми.

Переписывай

Ты не привел никаких претензий, мне нечего переписывать, мне нравится текст.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Если у приложение есть архитектура, ТЗ, то это уже как минимум итеративная разработка, а не Agile. Agile вообще предписывает не иметь заранее определенной архитектуры, и вы не должны знать, что и как вы будете собирать из отдельных модулей, а решать этот вопрос непосредственно в процессе релизов — эти условия у тебя не выполняются, а значит ты описываешь не Agile. Еще и ко мне претензии предъявляешь.

ШТА???? Ты вообще Agile manifesto читал? Ну и да, когда приходит заказчик с заказом, никакой архитектуры нет, возможно, что есть функциональные требования. Разработка архитектуры - это часть работы, за которую платят.

Нет, вам пришлось отказаться от Agile, потому что Agile вам не подходит.

Тот agile, который ты описываешь, действительно не подходит. Причем никому.

PS Что-то вспомнился один гражданин, уверявший меня в том, что agile - это когда стоя работают.

CaveRat ★★
()
Ответ на: комментарий от byko3y

Agile вообще предписывает не иметь заранее определенной архитектуры, и вы не должны знать, что и как вы будете собирать из отдельных модулей, а решать этот вопрос непосредственно в процессе релизов

Прости, ты откуда этот бред выкопал?

leave ★★★★★
()
Ответ на: комментарий от byko3y

Что? Еще и меня в 4.2 обвиняет. Расскажи мне, как сервисы по сети, пусть и loopback-у, передают данные быстрее прямой записи в оперативную память, а я послушаю.

Мы тут про ресурсы ващет, а не про быстродействие. Придумай другую отмазку.

p.s. начинает пованивать сишечкой

Да. А вот PO/PM, как и EKL/MN — не являются общепринятыми.

В твоем мирке русскоязычной разработки - может быть. В реальности «а кто пээм проекта» слышишь на порядки чаще, чем «кто проектный менеджер проекта».

Ты не привел никаких претензий

Претензия от тебя была, что тебя не уважают, поскольку используют в речи англицизмы. Я прошу показать пример истинно русского текста.

leave ★★★★★
()
Последнее исправление: leave (всего исправлений: 3)
Ответ на: комментарий от leave

начинает пованивать сишечкой

Не фанат сишечки, но раз такое дело: что использовать нормальным пацанам?

anonymous
()
Ответ на: комментарий от leave

Претензия от тебя была, что тебя не уважают, поскольку используют в речи англицизмы.

Nope.

so you should try to respect other users

Please stop to harass the owl.

anonymous
()

Если у приложение есть архитектура, ТЗ, то это уже как минимум итеративная разработка, а не Agile. Agile вообще предписывает не иметь заранее определенной архитектуры, и вы не должны знать, что и как вы будете собирать из отдельных модулей, а решать этот вопрос непосредственно в процессе релизов — эти условия у тебя не выполняются, а значит ты описываешь не Agile. Еще и ко мне претензии предъявляешь.

Что-то вспомнилось, как некий эрзент писал крайне похожую по стилю муть про ITIL.

CaveRat ★★
()
Ответ на: комментарий от CaveRat

ШТА???? Ты вообще Agile manifesto читал? Ну и да, когда приходит заказчик с заказом, никакой архитектуры нет, возможно, что есть функциональные требования. Разработка архитектуры - это часть работы, за которую платят

Я читал, а ты читал? Особенно я имею в виду

Welcome changing requirements, even in late development
Best architectures, requirements, and designs emerge from self-organizing teams

Да, архитектура может быть, но на следующий день она будет изменена — и что это за архитектура? Как только вы вынуждаете кого-то следовать некой архитектуре, фиксировать ее — вуаля, у вас план, каскадная/итеративная разработка.

byko3y ★★★★
() автор топика
Ответ на: комментарий от leave

Agile вообще предписывает не иметь заранее определенной архитектуры, и вы не должны знать, что и как вы будете собирать из отдельных модулей, а решать этот вопрос непосредственно в процессе релизов

Прости, ты откуда этот бред выкопал?

Отсюда;

Welcome changing requirements, even in late development
Best architectures, requirements, and designs emerge from self-organizing teams

Я подчеркиваю слова из моей цитаты «заранее определенной архитектуры» — в Agile архитектура не определена заранее, она придумывается и изменяется на ходу.

byko3y ★★★★
() автор топика
Ответ на: комментарий от leave

Мы тут про ресурсы ващет, а не про быстродействие. Придумай другую отмазку

http://freebsdguide.ru/_19/_1/

В компьютере есть четыре основных ресурса: ввод-вывод, сетевая пропускная способность, память и процессор.

Претензия от тебя была, что тебя не уважают, поскольку используют в речи англицизмы. Я прошу показать пример истинно русского текста

Моя претензия была в том, что ты используешь набор случайных букв в своей речи.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от leave

начинает пованивать сишечкой

не сишечкой, а Эдичкой. вовсю уже смердит

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.