Перейти к содержимому
Форумы SkyCentre Прыжки с парашютом
mmoustaf

Программисты философствуют

Recommended Posts

Что за словоблудие? Ради искусства икебаны, что ли?

Я ничего не перепутал?

Да, ради икебаны. Задачи на олимпиадах - это типичная икебана.

А в жизни, когда тебе приходит бизнес-реквест, часто получается, что пользователь хотел не только этого, или не этого вообще.

Быдлокодер - он реквест исполнит, пусть даже олимпийским кодом, а потом начнет: этого не было в спеке, этого тоже.

Сами виноваты, что не так работает.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Да, ради икебаны. Задачи на олимпиадах - это типичная икебана.
Нет, не икебана. Спорт (мотивация) и искусство (ценность результата) — да. Вид — нет.

Это, как ни крути, программирование, а не мелкая моторика и чувство формы и цвета.

Программист уже давно не просто кодит. Поэтому, тот кто только программирует - быдлопрограммер.
Какой перекос в терминологии! Да уж, отстал я от жизни. „Обычной“.

Тот, кто только кодит, то не программер, а кодер. Возможно, „быдло“ — зависит от качества результатов его деятельности.

Программист, помимо кодерства (которое он должен уметь) обязан думать о решении конечной задачи. Иначе он просто кодер. Причём, программист тоже может быть „быдло“ — зависит от его способности анализировать и выбирать наибоее подходящие для задачи архитектуру, инструменты… И быдлопрограммер ≠ кодер, ибо его функции (изначально, по идее) иные, просто он такой хреновый программист.

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

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

Я пока только ещё более утвердился во мнении, что „всё смешалось в доме…“.

PS. Как может так „съезжать“ терминология в, казалось бы, далеко не гуманитарной области? Это, что, эффекты замкнутых сообществ? Локальная профессиональная деформация в отдельно взятом месте/коллективе? Поразительно.

Поделиться сообщением


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

Это как раз его основная деятельность. Точнее потихоньку плавно перетекает туда.

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

PS. Как может так „съезжать“ терминология в, казалось бы, далеко не гуманитарной области? Это, что, эффекты замкнутых сообществ? Локальная профессиональная деформация в отдельно взятом месте/коллективе? Поразительно.

Здравствуйте, доктор.

Нет, не икебана. Спорт (мотивация) и искусство (ценность результата) — да. Вид — нет.

Это, как ни крути, программирование, а не мелкая моторика и чувство формы и цвета.

Это именно "моторика" и "чувство формы", только для мозга.

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

Никто ж не говорит, что это плохо.

Это очень клево.

К сожалению в реальных проектах это не всегда применимо.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
От обычной.

Программист уже давно не просто кодит

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

Это относится к уровню в иерархии.

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

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

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

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

"маляра Шлемиэля..."
Маляр Шлемиэль подрядился красить пунктирные осевые линии на дорогах. В первый день

он получил банку краски, поставил ее на дорогу, и к концу дня покрасил 300 метров осевой

линии. "Отлично!" сказал прораб, "быстро работаешь!" - и заплатил ему копейку.

На следующий день Шлемиэль покрасил 150 метров. "Мда, это, конечно, не так здорово, как

вчера, но приемлемо", - сказал прораб и заплатил ему копейку.

На следующий день Шлемиэль покрасил 30 метров. "Всего лишь 30!" заорал прораб. "Это

никуда не годится! В первый день было в десять раз больше! В чем дело?"

"Ничего не могу поделать," - говорит Шлемиэль. "Каждый день я ухожу все дальше и

дальше от банки!"

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
странно, с каких пор эффективный исполнитель стал быдлокодером?

С тех пор как мало быть только эффективным исполнителем.

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

Это как раз правильная организация работы.

Каждый член команды должен быть не только программистом.

И очень желательно чтобы так было.

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

И если этот ас уберется на низком развороте, то всему проекту придет полный и неотвратимый пиндец.

Это во-первых.

А во-вторых, не обязательно быть супер-пупер асом в программировании.

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

Эффективного аса можно позвать на тренинг по передаче знаний. Больше в общем-то он и не нужен.

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

Это такой же миф как и то, что аджайл - это "по русски тяп-ляп".

Другое дело, что аджайл не везде применим.

И ваще вы все так возбухаете. как будто быдлокодер в вашем понимании - это что-то плохое.

Поделиться сообщением


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

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

И если этот ас уберется на низком развороте, то всему проекту придет полный и неотвратимый пиндец.

наличие аса в программирование != наличию единственного и неповторимого исполнителя. Наличие аса программирования == эффективные решения задач, отсутствие аса == не самые эффективные решения задач.

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

правильно, но с оговорками. Ты часто видел программистов, которые могут реально заменить дизайнера? именно заменить, а не так, пару каких то финтифлющек прикрутить. Или программиста, который может заменить технолога по расчету себестоимсоти производственного процесса? или программиста, способного заменить технолога на линии в цеху? или заменить схемотехника оп разводке печатных плат? все вопросы - из живых примеров проектов моих.

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

Эффективного аса можно позвать на тренинг по передаче знаний. Больше в общем-то он и не нужен.

все зависит от сложности проекта. на мелких проектах обычно ас нерентабелен.

И ваще вы все так возбухаете. как будто быдлокодер в вашем понимании - это что-то плохое.

потому что каждый о своем определении говорит. Дай определение быдлокодера.

Поделиться сообщением


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

Не так.

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

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

наличие аса в программирование != наличию единственного и неповторимого исполнителя. Наличие аса программирования == эффективные решения задач, отсутствие аса == не самые эффективные решения задач.

Не самые эффективные лучше чем неэффективные вообще.

Наша задача выдать продукт.

По возможности максимально эффективный.

Но если он будет не самый эффективный - это не страшно.

Поэтому в команде не нужны асы.

Асов можно сделать самим.

правильно, но с оговорками. Ты часто видел программистов, которые могут реально заменить дизайнера? именно заменить, а не так, пару каких то финтифлющек прикрутить. Или программиста, который может заменить технолога по расчету себестоимсоти производственного процесса? или программиста, способного заменить технолога на линии в цеху? или заменить схемотехника оп разводке печатных плат? все вопросы - из живых примеров проектов моих.

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

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

У нас таких достаточно.

Есть и простые "эффективные исполнители"

все зависит от сложности проекта. на мелких проектах обычно ас нерентабелен.

Да и на больших тоже. Если его именно как кодера использовать.

потому что каждый о своем определении говорит. Дай определение быдлокодера.

так я его и дал уже выше.

Это такая роль.

Каждый программист он периодически быдлокодер. Но только частично.

К качеству кода это не имеет никакого отношения.

Поделиться сообщением


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

я вижу иногда такого)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Не так.

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

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

давай на примерах?

дано: проект, в котором есть фронт (веб приложение, программист и дизайнер+верстальщик), бэк (десктоп, три программера) и сервис, который обслуживает данные с фронта, бэка и еще пары автоматизированных связанных сервисов (три программера). Есть ПМ, который "активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях". Еще есть 4 человека тестеров. Есть еще системный архитектор, но он на данном этапе работы привлекается эпизодически, поскольку архитектура им уже была создана и идет наполнение ее мясом.

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

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

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

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

Не самые эффективные лучше чем неэффективные вообще.

Наша задача выдать продукт.

По возможности максимально эффективный.

Но если он будет не самый эффективный - это не страшно.

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

есть проекты (или задачи в проекте), которым пофиг как она решена программно. Есть задачи, которые крайне критичны к реализации - большие данные, малые длительности процессов, большая ответственность (типа аэро-милитари-мэдикал приложений). Если это печать 3-х накладных на предприятии в день - какая разница, будет ли печать идти на две минуты дольше или иногда зависать. Если это учетка холдинга с 5-ю заводами - то глюк конвертируется в пятизначную сумму. Не смогли овормить 20-и тонный молоковоз, молоко прокисло.

Повторюсь - есть проекты, критичные к реализации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Alkinoy, вы на все смотрите через призму веб программирования - не везде процесс разработки поставлен так - приходит заказчик - говорит - "хочу сайт и чтобы круто было и завтра и забесплатно" и орава быдлокодеров начинает его ублажать. Многие конторы создают продукт сначала, а потом его продают и каким этот продукт будет - зависит не от пожелания заказчика, а от того - каким его видит лидер команды. За примерами далеко ходить не надо - та же Apple - две большие разницы - присасываться к существующей нише и открывать конвейер по производству одноразовых продуктов по требованиям заказчика или создавать свою нишу. Когда то люди не знали что такое ПК - если бы все разработчики сидели и ждали когда к ним придет заказчик и подробно опишет им каким должен быть компьютер - вряд ли мы бы сейчас писали в интернетах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SlavikMIPT, нет, не через веб. просто в веб это более ярко видно (кстати, в вебе много компаний со своими продуктами тоже есть). Это из опыта в проектах под веб, 1С и железячек (контроллеры, ПЛИС). Есть особенности в каждой отрасли, но принципы построения работы одинаковы.

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

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

это больше вопрос маркетнига, чем программирования (то есть производства).

Поделиться сообщением


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

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

Поделиться сообщением


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

угу и в идеале это трёхголовый змий из проджект менеджера, продакт менеджера и маркетолога, плотно работающий с командой с одной стороны и заказчиком\потенциальной аудиторией\аналитикой с другой)

Поделиться сообщением


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
давай на примерах?

дано: проект, в котором есть фронт (веб приложение, программист и дизайнер+верстальщик), бэк (десктоп, три программера) и сервис, который обслуживает данные с фронта, бэка и еще пары автоматизированных связанных сервисов (три программера). Есть ПМ, который "активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях". Еще есть 4 человека тестеров. Есть еще системный архитектор, но он на данном этапе работы привлекается эпизодически, поскольку архитектура им уже была создана и идет наполнение ее мясом.

Я работаю в большом проекте критичном к реализации в большой психбольнгице.

У нас есть фронт - трейдеры, мидл - TMG, и бэкофис

Это трейдинговые системы. Там ответственность и быстродейтвие такие, какие не снились никому.

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

Легко и просто.

Толку с того, что у ПМ есть бизнес знания.

Делает-же не ПМ, а программист.

А если у программера вопросы к пользователю, он к ПМу идет?

А если решение требует пересмотра архитектуры - к архитектору?

Концепция ПМа в таких проектах зачастую абсурдна.

У пользователя есть свой реквест.

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

То как систему запроектировал архитектор еще больше уводит все от того, что хочет пользователь.

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

А если в результате вышло эффективное "не то", то виноват тестер. или архитектор или ПМ или даже юзер который не все сказал.

Правда?

В результате получаем тупик и переделки эффективного кода..

У нас нет ПМа у нас есть продакт-овнер.

Роль ПМ играет вся команда целиком.

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

А с пользователем мы общаемся сами.

Продакт овнер нам помогает донести, что мы не можем или можем сделть, что-то лишнее и т.д.

То есть он нас оберегает.

И код у нас может не супер эффективный. но система в целом

- удовлетворяет наиважнейшим требованиям пользователя

- быстро реагирует на изменения

- непрерывно развивается

- эффективна в смысле запасов прочности.

erling9, нет - просто спец, который мог бы сделать работу каждого из команды, но у него на это нет времени - поэтому он руководит

даже больше.

У него нет таких умений, но он строит эффективную работу.

Ты описал скраммастера

Спор с Мансуром у нас по поводу исполнителей - для серьезного проекта я предпочту команду грамотных однопрофильных специалистов команде разностаночиков

Не разностаночников, а многофункциональных товарищей.

Несомненно у каждого есть сильные области действия.

Но команда в целом более самоорганизуема и независима.

А если один однопрофильник задерживает всех, то что?

Или в отпуск ушел а тут.

И вообще алго-трейдинг, или позишн-кипинг для трейдинга на весь банк - это серъезно или нет?

угу и в идеале это трёхголовый змий из проджект менеджера, продакт менеджера и маркетолога, плотно работающий с командой с одной стороны и заказчиком\потенциальной аудиторией\аналитикой с другой)

Нет

Проджект менеджер - лишнее звено

С заказчиком работает вся команда целиком.

И в аналитике участвует она же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
С заказчиком работает вся команда целиком.

И в аналитике участвует она же.

Это не всегда работает. Особенно не работает, когда заказчик отсутствует, а аналитика сложная, объёмная и не очень однозначная. Я просто в геймдеве работаю, своя специфика есть. Для нас подход, который я описал выше, здесь работает достаточно хорошо за ооочень редкими исключениями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Толку с того, что у ПМ есть бизнес знания.

Делает-же не ПМ, а программист.

А если у программера вопросы к пользователю, он к ПМу идет?

А если решение требует пересмотра архитектуры - к архитектору?

У нас нет ПМа у нас есть продакт-овнер.

Роль ПМ играет вся команда целиком.

С заказчиком работает вся команда целиком.

И в аналитике участвует она же.

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

А как руководство компании получает понятия о текущем состоянии дел? Каждый программист сам отчитывается? Это или ад, или у вас маленькая компания. сколько человек, если не секрет?

А если один однопрофильник задерживает всех, то что?

Или в отпуск ушел а тут.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Начитался слов: аджайл, скрам, кризисное программирование, мифический человеко-месяц и думаешь, что мы поверим, что ты такой умный :)

Не, у нас такое реально работает.

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

А скрам и аджайл работает в соседней команде и не в одной на ура.

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

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

Во-первых - это очень полезная вещь. У нас, например, каждый имеет свою сильную сторону и периодически устраиваются семинары, где он рассказывает остальным какие-то интересные моменты из своей области. Во-вторых, если ты попадаешь к настоящему асу, то, как написал однажды мой знакомый: "Идет 2-й день семинара, ощущаю себя полным идиотом", или как было в видео, на которое я давал линк "Я бы тоже хотел думать головой". Узнаешь совершенно неочевидные вещи. В третьих ас гораздо быстрее может разобраться с проблемой, что крайне важно в случаях ситуаций приоритетом в 1.

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

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

В моем понимании плохое - это говнокодер. И тебе видимо тоже попался говнокодер.

А быдлокодер это нормально.

Ну давай я назову более длинно - массовый типа программиста или 95% программистов.

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

Массовый то бишь.

И ничего плохого в этом нет.

Не, если не нравится слово быдло. ну давай заменим на политкорректный термин.

будет массовый тип програмиста.

а говнокодер - альтернативно одаренный программист.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
У пользователя есть свой реквест.

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

То как систему запроектировал архитектор еще больше уводит все от того, что хочет пользователь.

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

А если в результате вышло эффективное "не то", то виноват тестер. или архитектор или ПМ или даже юзер который не все сказал.

Правда?

В результате получаем тупик и переделки эффективного кода..

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

У нас нет ПМа у нас есть продакт-овнер.

Роль ПМ играет вся команда целиком.

Проджект менеджер - лишнее звено

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

Особенно не работает, когда заказчик отсутствует

это как???

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А как руководство компании получает понятия о текущем состоянии дел? Каждый программист сам отчитывается? Это или ад, или у вас маленькая компания. сколько человек, если не секрет?

Эээ...

заказчик получает демонстрацию в конце каждого спринта.

Руководство получает отчет на основании бэклога, заказчик тоже.

В бэклоге есть то что мы сделали и то, что мы не сделали.

А также то. что мы планируем сделать в этом спринте.

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

Не у меня. В жизни.

В жизни все факапы случатся как обычно внезапно.

Более того ПМ, как ключевая точка тоже может внезапно выйти из строя.

И команда должна суметь среагипровать именно при внезапном изменении.

В наихудшем, то бишь, случае.

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

Игорь ответил.

Поделиться сообщением


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

Для этого есть, например, Скрам-Мастер. Существуют два принципиально разных вида девелоперов:

- Одни ...

- Другие ...

Вот! Первых я называю быдлопрограммеры. Потому, что это массовый сейчас тип.

Про других...

Недостатки: таких девелоперов очень мало (мы, например, до сих пор не можем найти нужне количество), они дорогие.

ну они дорогие потому, что их мало.

И за них бьются, да.

У нас кстати в конторе их щас выращивать начали, реально.

Ну и набирали тоже таких.

Я пошутил :) У нас у самих Скрам, он отлично работает.

Да я понимаю, что пошутил - это больше в аудиторию было.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Это не всегда работает. Особенно не работает, когда заказчик отсутствует, а аналитика сложная, объёмная и не очень однозначная. Я просто в геймдеве работаю, своя специфика есть. Для нас подход, который я описал выше, здесь работает достаточно хорошо за ооочень редкими исключениями.

Если заказчик отсутствует - то продукт никому не нужен.

Как ты думаешь для кого вы делаете продукт в геймдеве?

Поделиться сообщением


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

В вашем случае (геймдев) заказчик все равно есть.

И кстати в геймдеве скрам работает очень отлично, лучше всего кстати.

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

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

Поделиться сообщением


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

А кто пользуется продуктом геймдева?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×
×
  • Создать...