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

[erling9 148]

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

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

[mmoustaf 101]

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

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

[mmoustaf 101]

erling9,

Заказчик есть всегда, т.к. он определяет требования к проекту. Просто он может быть явным (издатель, продюсер и т.д.) и неявным - целевая аудитория, для которой разрабатывается проект. В Геймдеве кто-то должен определить финансовую модель игры, жанр, сеттинг, сюжет, мультиплеер и т.д. В противном случае получаем "Разработай то, не знаю что".

Блин, ты превратил коучинговую ситуацию в учительскую.

Я выводил человека на понимание открытыми вопросами. )

На самом деле так и есть. Пользователи хотят игру в которую было бы интересно играть.

Но они не могут сказать что именно они хотят - любую игру лишь бы интересно. То есть они являются заказчиками.

Но в т.н. "запутанном мире."

И команда геймдева этим и занимается, что собирает требования.

Чем ближе релиз тем теснее общение с пользователем.

Эрлинг сам все жто прекрасно знает.

"Разработай то, не знаю что".

ну да. С этого и начинается скрам.

Из не знаю, что получается то. что купит заказчик.

[erling9 148]

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

ну так я ж с этого и начал в своём первом посте) там просто разговор был о команде, менеджменте и связи команда-заказчик.

На самом деле так и есть. Пользователи хотят игру в которую было бы интересно играть.

Но они не могут сказать что именно они хотят - любую игру лишь бы интересно. То есть они являются заказчиками.

Но в т.н. "запутанном мире."

И команда геймдева этим и занимается, что собирает требования.

Точно. И что им интересно, они сами никогда не скажут, а если скажут, то неправду, потому что сами не знают. За них говорят тонны цифр статистики, переработанные и интерпретированные маркетологами. Между производственной командой и "заказчиком" у нас обязательно живёт прослойка из ПМов и маркетинга, плюс, кстати геймдиз

Эрлинг сам все жто прекрасно знает.

Меня Андрей зовут, будем знакомы

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

[mmoustaf 101]

Очень приятно.

Так и мы тут не спорим а философствуем

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

За них говорят тонны цифр статистики, переработанные и интерпретированные маркетологами.

Между производственной командой и "заказчиком" у нас обязательно живёт прослойка из ПМов и маркетинга, плюс, кстати геймдиз

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

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

Ну вот вы сделали альфа версию.

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

Только спросив у них.

Не у ПМа, не у маркетинга, а у них.

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

Где тут ПМ?

А нету его тут.

В лучшем случае вы получите то. что хочет ПМ, а не то. что хочет юзер.

[erling9 148]

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

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

Если 70% юзеров поиграли один раз 2 минуты, не прошли первый уровень и игру больше не открывали, значит скорей всего у игры высокий порог вхождения и\или обучение сделано плохо, если из 20 товаров внутреннего магазина покупают только 5, значит остальные бесполезны, либо у них завышена цена. Большинство бросило игру после 1\3 прохождения - интерес пропал, либо сложность резко возросла.

На 90 процентов вот так происходит опрос пользователей и никак иначе

[mmoustaf 101]

.

На 90 процентов вот так происходит опрос пользователей и никак иначе

А на остальные 10% как?

[Justas 9]

флудеры

[mmoustaf 101]

флудеры

можно подумать остальные тут парашютным спортом занимаются.

[Alkinoy 56]

Игорь, Мансур, вы пишите много, мне одному не успеть. поэтому попробую в одном посте.

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

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

- Одни работают только из под палки, над ними постоянно должен стоять ПМ, Шеф отдела, от них надо постоянно требовать отчетов (лучше всего ежедневных): "Что написал, сука? Покажи в коде! А почему не закоммитил? А что помешало? А почему, сука, вчера не сказал, если уже вчера знал?" и т.д. и т.п. Преимущества таких девелоперов: их много, их не надо долго искать, они очень дешевые. Недостатки: требуют постоянного контроля, выдают такой код, что индусские программисты могут сильно им завидовать. Требуют тотального контроля до малейшиих мелочей.

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

Все равно, я не понял. Скрам, красивое слово, согласен, но.

1. как ты написал - скрам требует уникальных людей. Это минус - завтра у меня расширилась задача, но клиент сосет, потому что людей нет. И то пишут, что суперспец нафиг никому не нужен, что в лучшем случае только сходить на семинар - а потом выясняется, что для применения скрам технологии как раз и нужны уникальные люди - которых мало, которые дорогие и заменить которых практически невозможно. Вон Мансур писал про слившихся людей - а что, разработчики при скрам как то магически привязаны к проекту? Они оже могут заболеть/уехать/обидиться/свалить к конкуренту. и кем вы будете такого человека заменять? Так что тут получилась команда не с одним звездным спецом, а со всеми. А при нормальном подходе я могу менять/добавлять работников - потому что они есть. Их много. Цена их средняя. Опасность выбытия из команды участника - средняя или ниже средней. А при скраме - это почти пипец, получается.

Побеждает не звездная команда, а та, которая правильно управляется.

2. разработчики описаны как то однобоко - или полное дерьмо, или просто ангелы в сахарном сиропе. Вообще то там посередине обычных людей много. поговорите с любым вражеским (иностранным) спецом по производству - костяк производственной группы (программистов туда отношу тоже) в основном состоит из работников средней квалификации. Быдло/говнокодера ПМ выгонит из команды через неделю-другую. Потому что он не будет брать на себя ответственность за работу с таким человеком. И заменит его обычным.

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

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

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

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

[Justas 9]

можно подумать остальные тут парашютным спортом занимаются.

[333 546]

xD

Дык, поистаскались шапочки из фольги. Шож Ви хочите? Фукусима, HAARP, магнитные бури не дремлют!

[mmoustaf 101]

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

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

Как раз скрам позволяет оценить положение дел.

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

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

Fidessa, например

Скрам - это как раз для тех, кто не "ноет на форуме о бесплатных прыжках", простите мне такую шпильку

Но скрам применим не везде - это да.

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

При аджайле мы декларируем что:

- фиксируем сроки, цену и производительность, но не фиксируем объем

мы гарантируем что в конце заказчик получит работающий продукт

- Обойдемся без срыва сроков и обёма бюджета

- там будет все самое важное для него

-любые изменения в процессе разработки - бесплатно

- заказчик будет находиться в курсе всего постоянно

Он каждый спринт будет видеть что получается

И конечно же он будет недоволен, но в процессе разработки это будет исправляться.

Да он первым делом скажет в конце первого спринта: "Эу вы че? Как вы пнл посчитали? Че вы адр с андерлаингами не консолидируемое?"

Мы в бэклог раз такие и добавили задачу - сделать конвертируемость и консолидацию цб.

По важности отсортировали.

Плана нет

Есть бэклог, задачи разбиты по важности и первоочередности

Есть известная производительность команды.

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

Понятное дело, что команда подписывается на задачи так, чтобы оставалось время на багфикс

В конце спринта - демо

Каждый день - планерка, стендах.

Если Вася не успевает - об этом максимум узнается на след день.

Далее несколько вариантов

- вася справляется сам (часть задач передается команде)

- команда помогает Васе решить данную задачу

- если нет задача может вернуться в бэклог

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

В конце спринта демо заказчику - по результатам - обновление бэклога

Потом ретроспектива

Скрам мастер никем не рулит - он наблюдает и говорит - где и чо поправить в процессе

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

И по новой - след спринт.

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

А то чего нет - оно обычно ему и не нужно.

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

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

Побеждает не звездная команда, а та, которая правильно управляется.

Именно - скрам это и есть управление такой командой

Точнее команда управляется сама, а скрам позволяет делать это эффективно

Что касается вылета людей - так на то и кроссфункциональная команда, что один кк член заменяет выбывшего

Гугли карту звездного неба (стармап)

[mmoustaf 101]

2. разработчики описаны как то однобоко - или полное дерьмо, или просто ангелы в сахарном сиропе.

Где?

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

Во-первых, почему не масштабируем? Кто это тебе сказал? Это ты сам себе придумал.

То же самое про единость.

Во-вторых, тебе что важнее? Концептуальность? Или чтобы работало?

[maksims 1]

...

- Обойдемся без срыва сроков и обёма бюджета

...

-любые изменения в процессе разработки - бесплатно

...

А можно вам заказать тетрис, а потом пожелать изменить его на Quake3?

За те же деньги и без срыва сроков справитесь?

[Alkinoy 56]

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

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

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

размер команды никак не влияет на организацию процесса: хоть 10 человек одновременно девелопят, хоть 100.

а где их взять таких - много?

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

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

Понятное дело, что команда подписывается на задачи так, чтобы оставалось время на багфикс

...

Если Вася не успевает - об этом максимум узнается на след день.

Далее несколько вариантов

- вася справляется сам (часть задач передается команде)

- команда помогает Васе решить данную задачу

- если нет задача может вернуться в бэклог

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

Не понятен механизм узнавания на следующий день. спринт - месяц. Что бы сказать - я не успеваю - надо видеть отставание от плана. которого нет. Или Вася сам в голове всегда четко видит планируемую разработку с учетом багфикса и так точно может прогнозировать неуспевание? джедаи, кругом одни джедаи. Но в обычной жизни отставание становится понятно разработчику где то в районе прошествия 70% времени. То есть за неделю до конца спринта. Как же он на след день после начала отставания видит это? мне не понятно. и не совсем понятен вопрос о прерывании спринта и возвращении задачи в пул - кто принимает такое решение?

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

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

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

Где?

вот тут:

- Одни работают только из под палки, над ними постоянно должен стоять ПМ, Шеф отдела, от них надо постоянно требовать отчетов (лучше всего ежедневных): "Что написал, сука? Покажи в коде! А почему не закоммитил? А что помешало? А почему, сука, вчера не сказал, если уже вчера знал?" и т.д. и т.п. Преимущества таких девелоперов: их много, их не надо долго искать, они очень дешевые. Недостатки: требуют постоянного контроля, выдают такой код, что индусские программисты могут сильно им завидовать. Требуют тотального контроля до малейшиих мелочей.

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

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

то есть получается самый худший вариант планирования - на все задачи один дэдлайн. И как вы задолго до релиза увидите отставание, если плана то нет? То есть ситуация стандартная - прошло 70-80% времени и тогда становится понятным - упс, не успеваем. А при наличии проектного менеджмента отставания будут видны в течении недели...

[t-80 7]

Alkinoy, ну как же нет плана? Ведь каждый спринт - это и есть своего рода пункт плана.

[Alkinoy 56]

Alkinoy, ну как же нет плана? Ведь каждый спринт - это и есть своего рода пункт плана.

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

[mmoustaf 101]

А можно вам заказать тетрис, а потом пожелать изменить его на Quake3?

За те же деньги и без срыва сроков справитесь?

Можно.

Конечно.

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

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

мы будем делать то, что ты скажешь и то с чем ты согласишься.

Я же говорю - в аджайле фиксируется бюджет. срок и производительность.

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

То есть по сути ПМом является заказчик? хорошо, если он компетентен это выполнить... Тогда даже плюс - вы перенесли свои затраты на содержание ПМа на заказчика smile.gif но обычно - заказчик не справляется...

Ты не поимаешь.

ПМа -нет

[mmoustaf 101]

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

Скрам мастер - выявляет проблемы процесса.

Отставания выявляет для себя каждый член команды.

Команда общяается на митинге.

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

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

Увидел проблему - тоже доложился.

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

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

А на багфикс всегда выделяется время.

Если же на багфикс постоянно уходит по 30% времени например. то явно что-то не то внутри команды, надо оптимизировать процесс.

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

Это у вас так.

А у нас гораздо раньше видно.

Механизм - ежедневный стендап.

О прерывании спринта - это редкий случай. но решение принимает команда. вместе. Целиком. Сама.

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

Нет.

Нету ПМа. ПМ - это вся команда целиком.

Скрам-мастер он вообще только наблюдает и говорит на ретроспективе - чуваки, у вас проблемы тут, тут и тут. давайте думать как решать?

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

а где их взять таких - много?

Так за ними теперь все охотятся, потому что это работает.

скрам это еще и двигатель организационных изменений.

В общем как Крейзи-Еленке в споре про АФФ против 2 программы, когда ей оплачивали курс рв, я могу тебе посоветовать одно - хочешь я оплачу тебе скрам тренинг трехдневный.

И ты сам все поймешь и задашь вопросы.

[mmoustaf 101]

Я завидую скрам-тренерам : сколько бабла можно срубить, объясняя людям казалось бы очевидные вещи.

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

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

А можно мне? Я тоже прикинусь, что не врубаюсь.

Организуем контору на троих?

[Alkinoy 56]

Я же говорю - в аджайле фиксируется бюджет. срок и производительность.

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

а разве из бюджета, срока и производительности не вычисляется объем?

И как то грустно, что основной аргумент - "ну ты не понимаешь!". Я хотел услышать примеры от команд, которые работают в таком режиме...

А можно мне? Я тоже прикинусь, что не врубаюсь.

Я завидую скрам-тренерам : сколько бабла можно срубить, объясняя людям казалось бы очевидные вещи.

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

[mmoustaf 101]

Я хотел услышать примеры от команд, которые работают в таком режиме...

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

Реальных.

Еще раз приведу список из моих сообщений.

Алго-трейдинг, трейдинг, позишн-кипинг, валютный трейдинг.

Я лично использую его частично - поскольку моя команда разделена на две части (Москва - Лондон) и скрам-мастер в Лондоне больше фурычит с ними.

Для того чтобы мы не страдали, московская часть выделена отдельно. И мне приходится совмесщать фунции скраммастера и дева (что нехорошо)

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

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

http://www.fidessa.com/

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

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

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

[mmoustaf 101]

У нас программные комлексы для организации работы радио и ТВ станций.

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

[Justas 9]

так аджайл или скрам???