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

[mmoustaf 101]

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

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

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

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

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

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

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

[333 546]

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

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

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

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

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

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

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

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

Кто ж спорит.

…а вот бузи нес и потоки…

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

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

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

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

[mmoustaf 101]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

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

[Alkinoy 56]

От обычной.

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

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

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

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

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

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

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

"маляра Шлемиэля..."

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

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

странно, с каких пор эффективный исполнитель стал быдлокодером?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Alkinoy 56]

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

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

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

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

Не так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[SlavikMIPT 73]

или заменить схемотехника оп разводке печатных плат?

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

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

[Alkinoy 56]

Не так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[SlavikMIPT 73]

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

[Alkinoy 56]

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

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

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

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

[SlavikMIPT 73]

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

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

[erling9 148]

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

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

[SlavikMIPT 73]

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

[mmoustaf 101]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правда?

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

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

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

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

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

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

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

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

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

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

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

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

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

даже больше.

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

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

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

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

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

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

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

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

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

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

Нет

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

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

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

[erling9 148]

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

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

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

[Alkinoy 56]

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

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

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

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

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Alkinoy 56]

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

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

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

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

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

Правда?

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

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

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

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

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

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

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

это как???

[mmoustaf 101]

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

Эээ...

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

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

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

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

Скрам, Скрам, Скрам. Много читаем и ответы приходят сами по мере чтения.

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

- Одни ...

- Другие ...

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

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

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

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

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

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

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

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

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

[mmoustaf 101]

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

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

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

[erling9 148]

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

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

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

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

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

[mmoustaf 101]

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

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