Здравствуйте, Ikemefula, Вы писали:

НС>>Стандартный современный проджект.
I>Я бы сказал проджект где то из нулевых Он у тебя как то втёмную работает.

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

I>Вот заказчик вдруг захотел всё и сразу, к кому ему идти менять планы?

К продакту. А ты предлагаешь разрешить заказчику через голову продакта рулить напрямую разработкой? Особенно весело это будет выглядеть в случае коробки.
Я, кажется, начинаю понимать откуда такие странные предстаыления о роли проджекта. Ты не в аутсорсе, случаем, работаешь? Так там продакт на стороне заказчика, вот и получается такая странная картина. Как только мы понимаем что продакт это, на самом деле, не заказчик, а часть команды по разработке, а заказчик это тот кто платит за конечный продукт, а не за аутсорс части разработки, то все встает на свои места.

I>1 Продакт формулирует нечто, что позже превратится в требования. Обычно от заказчика поступают хотелки. От продакта нужно внятное понимание проблемы. Он один или с БА, формулируют предложения и согласовывают, делают мокапы.
I>2 Архитектор дополняет эти предложения нефункциональными требованиям, делает пок, прототип или что там надо. Далее, архитектор сам или с командой, делают эстимейты. Продакт с БА так не могут — они не в курсе про нефункциональные требования, ограничения, и эстимейты дать не могут.
I>3 После согласования у нас уже есть требования, которые снова описывает продакт или БА в более менее внятном виде.

Ну то есть с заказчиком общается продакт, а не проджект.


I>4 Проджет с одной стороны следит за этим процессом, выстраивает пайплайн,

Что такое в твоем понимании пайплайн?

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

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

I>Все трое работают вместе и итерационно, на каком то этапе подключается уже команда разработки.

Проджект это и есть часть команды разработки.

I>>> План намечается без участия заказчика?
НС>>План реализации? Разумеется без, зачем заказчику внутренняя кухня?
I>

То есть объяснить зачем заказчику нужно влазить во внутренние планы разработчиков ты не можешь. Или речь опять про аутсорс, где заказчик не продукт заказывает, а разработку?

Здравствуйте, Poopy Joe, Вы писали:

PJ>У нас простое правило — все решения должны снижать известный технический долг.

Тут что то не так. Если все решения снижают техдолг, то откуда он берется?

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Стандартный современный проджект.
I>>Я бы сказал проджект где то из нулевых Он у тебя как то втёмную работает.

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

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

I>>Вот заказчик вдруг захотел всё и сразу, к кому ему идти менять планы?

НС>К продакту. А ты предлагаешь разрешить заказчику через голову продакта рулить напрямую разработкой? Особенно весело это будет выглядеть в случае коробки.

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

I>>3 После согласования у нас уже есть требования, которые снова описывает продакт или БА в более менее внятном виде.

НС>Ну то есть с заказчиком общается продакт, а не проджект.

Ога, эдакий всемогутор — может и вместо архитектора, и вместо всех ба разом, и вместо всех дизайнеров, да еще и по процессам, планированию, бюджетам и стаффингу и тд

I>>4 Проджет с одной стороны следит за этим процессом, выстраивает пайплайн,

НС>Что такое в твоем понимании пайплайн?

Процесс.

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

НС>И каким местом тут общение проджекта и заказчика? У проджекта на входе требования, сформированные продактом. Да и то, требования ему постольку, поскольку, чтобы отследить их выполнение и понять что писать в стори тикете. Напрямую с требованиями он не работает.

Проектный менеджер посещает ключевые митинги, иначе о проблемах будет узнавать с задержкой в месяц-два в лучшем случае. Если каждый раз продакт будет бегать к проджекту "а вот такой вариант успеем до осени?" то никакого релиза не будет.

I>>Все трое работают вместе и итерационно, на каком то этапе подключается уже команда разработки.

НС>Проджект это и есть часть команды разработки.

Команда разработки это девелоперы. И архитекторов, если их несколько. Команд разработчиков может быть больше одной. Роль архитекторов — согласование, координация таких вот команд. Тестеры это команда тестирования. Идея понятна? БА если их больше одного, это тоже команда.
А вот проектный менеджер окучивает все эти команды, т.к. они работают на конкретный проект. Очевидно, он не может быть частью каждой из них.

НС>То есть объяснить зачем заказчику нужно влазить во внутренние планы разработчиков ты не можешь. Или речь опять про аутсорс, где заказчик не продукт заказывает, а разработку?

Аутсорс это терминология из 90х. Сейчас конторы примерно такие:
Внутренние продукты-сервисы, тогда заказчик — другой депертмент
Продукты на продажу, тогда заказчик это свой собственный департмент или так же другой департмент?
Провайдеры сервисов — еще куча вариантов, отличаются только тем, что различные позиции-роли распределены между внешним заказчиком и конторой. Например, внешний заказчик может выставить своих проектных и продуктовых менеджеров, а может выставить просто некое лицо, которое будет говорить "хорошо-плохо", а может до кучи и архитекторов предоставить.
Например, внешний заказчик может ограничиться минимальным участием, а может вплоть дойти вплоть до смешаных команд, часть людей вне зависимости от профиля, работают то там, то там.

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

Здравствуйте, Ikemefula, Вы писали:

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

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

I> С заказчиком на старте общаются разные люди — архитектор, ба, дизайнер и тд. Проджект — тоже. По вполне конкретным вопросам, например — планирование это его работа.

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

НС>>К продакту. А ты предлагаешь разрешить заказчику через голову продакта рулить напрямую разработкой? Особенно весело это будет выглядеть в случае коробки.
I>На одного продакта слишком много всего.

Какого такого всего? У продакта главная обязанность — общение с заказчиком/заказчиками и донесение результатов до проектной команды.

I>>>4 Проджет с одной стороны следит за этим процессом, выстраивает пайплайн,
НС>>Что такое в твоем понимании пайплайн?
I>Процесс.

Зачем тогда написал пайплайн? Чтобы запутать?

НС>>Проджект это и есть часть команды разработки.
I> Команда разработки это девелоперы.

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

I>А вот проектный менеджер окучивает все эти команды, т.к. они работают на конкретный проект.

Вот эти "все команды" и называется проектной командой.

НС>>То есть объяснить зачем заказчику нужно влазить во внутренние планы разработчиков ты не можешь. Или речь опять про аутсорс, где заказчик не продукт заказывает, а разработку?
I>Аутсорс это терминология из 90х.

Да как не обзывай, суть та же. Заказчик заказывает не готовый продукт, а его разработку под свое видение.

I> Сейчас конторы примерно такие:
I>Внутренние продукты-сервисы, тогда заказчик — другой депертмент
I>Продукты на продажу, тогда заказчик это свой собственный департмент или так же другой департмент?
I>Провайдеры сервисов — еще куча вариантов, отличаются только тем, что различные позиции-роли распределены между внешним заказчиком и конторой. Например, внешний заказчик может выставить своих проектных и продуктовых менеджеров, а может выставить просто некое лицо, которое будет говорить "хорошо-плохо", а может до кучи и архитекторов предоставить.
I>Например, внешний заказчик может ограничиться минимальным участием, а может вплоть дойти вплоть до смешаных команд, часть людей вне зависимости от профиля, работают то там, то там.
I>Нормальные конторы как правило смешаные, имеют весь набор вышеперечисленного. Крупные продуктовые гиганты которые работают полностью на себя как правило большая редкость, почти как динозавры.

Круто. К чему этот список?

Hobbes:

C>>... за пачку доширака в день. И чтобы еще пел, танцевал и нравился всему офису. А под "практическими задачами" обычно понимается разребание говнокода. Но называть его говнокодом ни в коем случае нельзя. Нужно называть это лидирущей в области высокотехнологичной системой. И не забывать улыбаться перед и после очередного нырка. И навсегда забыть про рефакторинг, потому что он "не увеличивает business value".
C>>Как-то так

H>А разгребание говнокода — это не рефакторинг? Я-то думал, что из говнокода сделать понятную систему с грамотной архитектурой это рефакторинг и есть.

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

Иногда так получается дешевле, но не всегда.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>С заказчиком много всего нужно обсуждать, кроме собтсвенно видения продукта.

НС>Зависит от заказчика. У аутсорсеров да, заказчик сильно вовлечен в процесс. У продуктовых компаний ситуация иная.

Ты пользуешься устаревшей терминологией. У продуктовых заказчик на 100% вовлечен в процесс: он же и менджмент, он же технари.

I>> С заказчиком на старте общаются разные люди — архитектор, ба, дизайнер и тд. Проджект — тоже. По вполне конкретным вопросам, например — планирование это его работа.

НС>Проджект, безусловно, может общаться с заказчиком по каким то деталям типа сроков демо, при условии что последний заинтересован в этом. Но это никоим образом не делает сей процесс его основной обязанностью. А вот у продакта это основная обязанность.

Заказчик хочет поменять сроки деливери, сообщает об это продакту, а тот будет пересаказывать проджекту? Это же сломаный телефон.

НС>Какого такого всего? У продакта главная обязанность — общение с заказчиком/заказчиками и донесение результатов до проектной команды.

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

НС>>>Что такое в твоем понимании пайплайн?
I>>Процесс.

НС>Зачем тогда написал пайплайн? Чтобы запутать?

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

НС>>>Проджект это и есть часть команды разработки.
I>> Команда разработки это девелоперы.

НС>А проджект это тоже девелопер.

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

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

>Ты, похоже, перепутал девелоперов с программистами. Вот у программистов обычно есть своя команда, а то и несколько. И все они входят в проектную команду. А так же туда входит проджект, команда тестировщиков, архитект и т.д.

Команда разработки и проектная команда соотносится как часть-целое, о чем я тебе пишу уже в третий раз.

>А вот продакт туда не входит.

Трудно уследить за полетом твоей мысли. Продакт то входит в эту команду, то не входит,
"продакт это, на самом деле, не заказчик, а часть команды по разработке," http://rsdn.org/forum/management/7771151?tree=tree

Автор: Ночной Смотрящий
Дата: 06.07.20

Ты определись, куда там у вас продакт входит

I>>А вот проектный менеджер окучивает все эти команды, т.к. они работают на конкретный проект.

НС>Вот эти "все команды" и называется проектной командой.

То есть, теперь тебе ясно, что каждая из этих команда по отдельности есть часть от проектной и имеет свое название?

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

I>>Аутсорс это терминология из 90х.

НС>Да как не обзывай, суть та же. Заказчик заказывает не готовый продукт, а его разработку под свое видение.

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

Под это определение подходят так же и внутренние сервисы — это всегда некто заказывает разработку под свое видение.

До кучи, продукт часто пишется в другой стране. Это аутсорс или нет? Гы-гы. Продуктовые конторы в нынешнее время вынуждены 'аутсорсить' чуть не вообще всё подряд. Открывают офис в другой стране, нанимают людей и всё.

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

I>>Внутренние продукты-сервисы, тогда заказчик — другой депертмент
I>>Продукты на продажу, тогда заказчик это свой собственный департмент или так же другой департмент?
I>>Провайдеры сервисов — еще куча вариантов, отличаются только тем, что различные позиции-роли распределены между внешним заказчиком и конторой. Например, внешний заказчик может выставить своих проектных и продуктовых менеджеров, а может выставить просто некое лицо, которое будет говорить "хорошо-плохо", а может до кучи и архитекторов предоставить.
I>>Например, внешний заказчик может ограничиться минимальным участием, а может вплоть дойти вплоть до смешаных команд, часть людей вне зависимости от профиля, работают то там, то там.
I>>Нормальные конторы как правило смешаные, имеют весь набор вышеперечисленного. Крупные продуктовые гиганты которые работают полностью на себя как правило большая редкость, почти как динозавры.

НС>Круто. К чему этот список?

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

Здравствуйте, Ikemefula, Вы писали:

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

О да, поспорить о терминах это лучший способ уйти от неудобной темы. Без меня.

I>Заказчик хочет поменять сроки деливери,

И опять скатываемся на аутсорс.

НС>>Какого такого всего? У продакта главная обязанность — общение с заказчиком/заказчиками и донесение результатов до проектной команды.
I>Представляю, как продуктовый менеджер, который отошел от технических вещей, а может никогда рядом с ними и не был, будет пересказывать архитектору изменение видения заказчика.

Продакт, который в плане видения продукта "никогда рядосм с ними и не был"?
Вот кто рассказывает вам видение — это как раз и есть продакт. Просто у вас в аутсорсе продакт чаще всего работает у заказчика.

НС>>Зачем тогда написал пайплайн? Чтобы запутать?
I>Ага, все вокруг тебя только и думают, как бы тебе нагадить.

Так зачем?

НС>>Да как не обзывай, суть та же. Заказчик заказывает не готовый продукт, а его разработку под свое видение.
I>Под это определение подходит и продуктовая контора, т.к. в большинстве своем менеджмент заказывает "его разработку под свое видение".

Это не определение, это попытка объяснить отличия.

I>До кучи, продукт часто пишется в другой стране. Это аутсорс или нет?

Зависит от того общие ли у них финансы.

I>Потому я и говорю, что термин аутсорс давно устарел.

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

НС>>Круто. К чему этот список?
I>Что бы показать, что индустрия давно уже не черно-белая.

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

I> Это только у тебя в голове все еще мифический аутсорс живет.

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

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

Провайдер сервисов не становится от этого аутсорсом.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>О да, поспорить о терминах это лучший способ уйти от неудобной темы. Без меня.

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

I>>Заказчик хочет поменять сроки деливери,

НС>И опять скатываемся на аутсорс.

Не надо ля-ля — эта ситуация 1 в 1 и в продуктах. Двигаются и релизы, и наборы фич, и степень проработки фич и что угодно.

НС>>>Какого такого всего? У продакта главная обязанность — общение с заказчиком/заказчиками и донесение результатов до проектной команды.
I>>Представляю, как продуктовый менеджер, который отошел от технических вещей, а может никогда рядом с ними и не был, будет пересказывать архитектору изменение видения заказчика.

НС>Продакт, который в плане видения продукта "никогда рядосм с ними и не был"?

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

НС>Вот кто рассказывает вам видение — это как раз и есть продакт. Просто у вас в аутсорсе продакт чаще всего работает у заказчика.

А в продуктовой конторе он типа может быть оторванным от заказчика?

"У вас в аутсорсе" — пудозреваю, все кто с тобой не согласен, работают в аутсорсе Ты этим кидаешься довольно регулярно. К слову, я как раз на продуктах, практически все 20 лет.

I>>Ага, все вокруг тебя только и думают, как бы тебе нагадить.
НС>Так зачем?

Пайплайн это конкретный случай процесса.

a route, channel, or process along which something passes or is provided at a steady rate; means, system, or flow of supply or supplies:
Freighters and cargo planes are a pipeline for overseas goods.

a state of development, preparation, or production
several projects in the pipeline
also : the system for such processes
a strong product pipeline

НС>>>Да как не обзывай, суть та же. Заказчик заказывает не готовый продукт, а его разработку под свое видение.
I>>Под это определение подходит и продуктовая контора, т.к. в большинстве своем менеджмент заказывает "его разработку под свое видение".

НС>Это не определение, это попытка объяснить отличия.

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

I>>До кучи, продукт часто пишется в другой стране. Это аутсорс или нет?

НС>Зависит от того общие ли у них финансы.

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

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

I>>Потому я и говорю, что термин аутсорс давно устарел.

НС>Да пофик на термин. Дело не в нем, а в сути — разные финансы подразумевают разные способы достижения коммерческой эффективности. И в больших конторах разница между FTE и различными видами аутсорса и аутстаффа вполне ощутимая, особенно на этапе бюджетов и планирования.

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

I>>Что бы показать, что индустрия давно уже не черно-белая.

НС>А никто про черно-белую и не говорил. Но то куда идет основная прибыль от конечного продукта накладывает вполне заметный отпечаток.

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

I>> Это только у тебя в голове все еще мифический аутсорс живет.

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

Без понятия, что там у тебя маловероятно. В чисто продуктовых регулярные премии хорошо если в одной из 10. А так в норме для финансирования продукта ведется разработка всего подряд по какой угодно схеме. А потом — бац — 9 из 10 продуктов себя не окупают и дохнут.

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

НС>Провайдер сервисов не становится от этого аутсорсом.

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

Здравствуйте, Vladek, Вы писали:

V>С точки зрения продажника и того, кто имеет доступ к доходам — конечно! Если что-то приносит доход, то зачем создавать риск этот денежный поток нарушить или вообще прерывать? Не трогай и делай то, что я говорю!

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Переделка GUI это не рефакторинг.

Почему это?

Здравствуйте, Codealot, Вы писали:

НС>>Переделка GUI это не рефакторинг.
C>Почему это?

По определению

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>По определению

Которому из, и какой из его трактовок?

Здравствуйте, Codealot, Вы писали:

НС>>По определению

C>Которому из, и какой из его трактовок?

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

Естественно, что и здесь надо вспомнить, что такое качество и степень соответствия — например, требовать 100% отсутствия любых признаков изменений смысла нет, это гарантировано недостижимо. То есть, если требовать гарантии 100% отсутствия признаков изменений, то под рефакторинг сойдет разве что переименование локальных переменных, и то не всегда. Отсюда ясно, что степень соответствия должна определяться целью.

Здравствуйте, Ikemefula, Вы писали:

I>Необходимость рефакторинга — это видение девелопера. Это он видит проблему и это его задача донести до менеджмента, объяснить, отстоять свою позицию.

С чего ты взял, что девелопер вообще должен что-то объяснять и доносить? Задача девелопера — кодить.

Здравствуйте, Ikemefula, Вы писали:

I>Если ты что либо переделываешь, то это никогда не бывает рефакторингом. Рефакторинг GUI, это, например, упрощение структуры при сохранении поведенческих, функциональных, визуальных свойств. Например — некто на форме слепил прямо по месту хитрый дропдаун. Можно вот это чудо заменить готовым дропдауном или выделить в отдельный кастомный элемент, т.е. всего лишь устранение дублирования. Если есть гарантии, что указаные выше свойства сохранены, не изменялись, то это будет рефакторинг.

I>Естественно, что и здесь надо вспомнить, что такое качество и степень соответствия — например, требовать 100% отсутствия любых признаков изменений смысла нет, это гарантировано недостижимо. То есть, если требовать гарантии 100% отсутствия признаков изменений, то под рефакторинг сойдет разве что переименование локальных переменных, и то не всегда. Отсюда ясно, что степень соответствия должна определяться целью.


Опять ты сам себе противоречишь.

Здравствуйте, IT, Вы писали:

I>>Необходимость рефакторинга — это видение девелопера. Это он видит проблему и это его задача донести до менеджмента, объяснить, отстоять свою позицию.

IT>С чего ты взял, что девелопер вообще должен что-то объяснять и доносить? Задача девелопера — кодить.

И давно у тебя коммуникация перестала быть обязанностью работника?

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

Здравствуйте, Codealot, Вы писали:

НС>>По определению
C>Которому из, и какой из его трактовок?

По общепринятой. Изменение UI это изменение видимого поведения, как сову на глобус не натягивай.

Здравствуйте, Ikemefula, Вы писали:

IT>>С чего ты взял, что девелопер вообще должен что-то объяснять и доносить? Задача девелопера — кодить.
I>И давно у тебя коммуникация перестала быть обязанностью работника?

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

I>Вот взял ты тикет, и видишь, что требуются изменения, которые затрагивают всех в команде.

Да у меня почти все тикеты такие.

Здравствуйте, IT, Вы писали:

>Коммуникацию как обязанность работника придумали те, кто кроме коммуникации делать больше ничего не умеет. Ещё раз повторяю, главная задача девелопера — кодить. Всё должно строится вокруг этого, а не вокруг коммуникации.

Работа без коммуникации невозможна в принципе. Сначала ты учишься коммуникации, а уже потом — программировать. И задачу надо сначала услышать, прочитать, понять, уточнить, предложить варианты решений, а уже потом начинать кодить.
Как только появились препятствия, здесь снова коммуникация — уметь найти того, кто починит сетку, базу и тд.
Без этого всего эффекта от твоего кодинга около нуля.

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

I>>Вот взял ты тикет, и видишь, что требуются изменения, которые затрагивают всех в команде.

IT>Да у меня почти все тикеты такие.

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

Здравствуйте, Ikemefula, Вы писали:

I>Работа без коммуникации невозможна в принципе. Сначала ты учишься коммуникации, а уже потом — программировать. И задачу надо сначала услышать, прочитать, понять, уточнить, предложить варианты решений, а уже потом начинать кодить.

Спасибо, кэп. Открыл глаза. Только это не коммуникация. Это обычный рабочий процесс. Ты сам определил коммуникацию как "его задача донести до менеджмента, объяснить, отстоять свою позицию". Вот этой фигнёй разраб заниматься не должен.

I>Как только появились препятствия, здесь снова коммуникация — уметь найти того, кто починит сетку, базу и тд.
I>Без этого всего эффекта от твоего кодинга около нуля.

Если ты всем этим занимаешься, то это однозначный индикатор наличия проблем в твоей команде.

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

И как часто ты без кодинга, но с коммуникацией взлетал проекты?

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

Железной ленейкой по пальцам. Не лезь куда не надо. Ты вообще о разделении работы в команде слышал?