Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 96
+ за публичную самокритику.
Хорошо написано, спасибо. Всплыли в памяти знакомые чувства «потерянных возможностей», когда понимаешь как нужно было делать :).
ИМХО только так становятся настоящими профи.
Удачи.
ИМХО только так становятся настоящими профи.
Удачи.
Спасибо парни,
Рядом новый проект сча начинается, я крепко задумался что очень не хочу той же задницы там, задумался что нужно сделать.
В общем очень рекомендую делать такие ревью.
Weekly, monthly, в конце проекта.
Рядом новый проект сча начинается, я крепко задумался что очень не хочу той же задницы там, задумался что нужно сделать.
В общем очень рекомендую делать такие ревью.
Weekly, monthly, в конце проекта.
Тоже понравилось, спасибо за опыт. Одно но — большое количество англицизмов, как колючки разбросанных по тексту, я понимаю — специфика отрасли не позволяет всё переводить дословно, но тут я даже не сразу догадался русский писал, или это переводная статья)
во-первых: спасибо автору, заставило задуматься и перепроектировать свою систему контроля и управления проектами, хоть и занимаюсь веб-девом.
KAFLAN: а по поводу «англицизмов» — тоже автору спасибо, я не имею технического образования (занимаюсь бизнес-процессами, то чего до конца не сделают технари) и мне достаточно тяжело тоже понимать то, что для многих, возможно, сегодня дают в университетах, а вот такие статьи помогают разобраться с хотя бы некоторыми терминами.
KAFLAN: а по поводу «англицизмов» — тоже автору спасибо, я не имею технического образования (занимаюсь бизнес-процессами, то чего до конца не сделают технари) и мне достаточно тяжело тоже понимать то, что для многих, возможно, сегодня дают в университетах, а вот такие статьи помогают разобраться с хотя бы некоторыми терминами.
Отличная статья. Всё честно, правильно и применимо к слишком многим в геймдеве. У нас были все те же самые проблемы и на больших и на маленьких проектах.
Жалко только, что слишком мало кто из игровых менеджеров может так откровенно и честно все написать, а все пишут постмортемы в стиле «все были хороши и все получилось, как задумано».
Выложи на dtf, пусть завидуют откровенности.
Жалко только, что слишком мало кто из игровых менеджеров может так откровенно и честно все написать, а все пишут постмортемы в стиле «все были хороши и все получилось, как задумано».
Выложи на dtf, пусть завидуют откровенности.
Оно кстати не токо к гейм деву очень хорошо относиться :)
Возле меня сейчас молодая команда во главе с опытным дядькой сайт ваяют… Я уже вижу и знаю что они опоздают на 3-4 недели. Они тоже видят, но боятся вот такой вот отрытой критики самих себя в открытую.
Возле меня сейчас молодая команда во главе с опытным дядькой сайт ваяют… Я уже вижу и знаю что они опоздают на 3-4 недели. Они тоже видят, но боятся вот такой вот отрытой критики самих себя в открытую.
Спасибо чув.
Выложил на дтф — но он там кажется мертв, нормальный народ там уже не тусит, по крайней мере в дискуссии не вступает.
Выложил на дтф — но он там кажется мертв, нормальный народ там уже не тусит, по крайней мере в дискуссии не вступает.
Ты — мужик.
Замечательная статья :) Я думаю, она поможет ещё ни одному начинающему девелоперу, который хочет работать «отдельно» от крупных компаний и творить что-то своё.
Зря закрытый топик сделал — так он не попадет в ленту хабры и тысячи людей, кто читает только ленту захабренных, ее не прочитают.
Лучше убрать замок и запись сразу попадет в rss захабренных :)
Лучше убрать замок и запись сразу попадет в rss захабренных :)
Зае… л не интернационал в ПО...!
Ну вобщем читая это понимаешь, почему в последнее время столько говна в играх. Все эти публичные альфа-бета тесты, закрываемые патчами после релиза. Вы будете гордится этой игрой? Ну флаг вам в руки…
Публичных тестов не будет.
Это всё были корридорные тесты + тесты на знакомых.
Мы не ПС рынок. Это на ПС делают как вы говорите.
На мобайл всё _очень_ жестко — есть NSTL, есть тестирование Verizon-a (на примере Verizon-a) — и даже если вы каким-то чудом с багом пройдете через тестинг — то 1-2 звонка в суппорт юзвера Verizon-a и игру снимут с продажи, им репутация очень дорога, им так проще, разбираться что там реально произошло они особо не будут.
Так что качество это для нас не пустой звук.
А это _очень_ большая проблема :)
Хотя за 5 лет уже без проблем проходим все эти тесты.
Это всё были корридорные тесты + тесты на знакомых.
Мы не ПС рынок. Это на ПС делают как вы говорите.
На мобайл всё _очень_ жестко — есть NSTL, есть тестирование Verizon-a (на примере Verizon-a) — и даже если вы каким-то чудом с багом пройдете через тестинг — то 1-2 звонка в суппорт юзвера Verizon-a и игру снимут с продажи, им репутация очень дорога, им так проще, разбираться что там реально произошло они особо не будут.
Так что качество это для нас не пустой звук.
А это _очень_ большая проблема :)
Хотя за 5 лет уже без проблем проходим все эти тесты.
Спасибо за статью. Прочитав задумался над процессом разработки своих проектов.
>> Грамотный лид программист Димусик тогда дочитывал Совершенный Код МакКоннела и смог
>> эффективно внедрить изложенные там идеи
Книга эта, если честно, не сказать чтобы кладезь идей… У нее немного другая направленность — не напичкать идеями, а привести в порядок все, что у программиста накоплено из опыта. Ну да ладно.
За статью большое спасибо. Многое напоминает собственный опыт :)
>> эффективно внедрить изложенные там идеи
Книга эта, если честно, не сказать чтобы кладезь идей… У нее немного другая направленность — не напичкать идеями, а привести в порядок все, что у программиста накоплено из опыта. Ну да ладно.
За статью большое спасибо. Многое напоминает собственный опыт :)
прочтитала на одном дыхании!
с нетерпением будем ждать вашей игры.
с нетерпением будем ждать вашей игры.
на dtf нет желания перепостить?
Ничо не понял, т.к. не фелолог, но читается на одном дыхании, прям экшн какой-то!
:)
:)
Не соглашусь по теме Agile. Это семейство методологий не требует тупого написания кода вместо предварительного обдумывания. Суть в том, что команда сама решает когда ей нужно продумать что-то изначально подробно, а потом делать, а когда можно начинать делать, а возможные изменения вносить по ходу.
Вы как раз и работали в Agile, применяя то подход предварительного полного продумывания, то кодирования с учетом непрерывного изменения (аля XP).
Противопоставление Waterfall и Agile уместно на более высоком уровне, то есть на уровне разработки большой части системы, а не конкретной фичи.
Вы как раз и работали в Agile, применяя то подход предварительного полного продумывания, то кодирования с учетом непрерывного изменения (аля XP).
Противопоставление Waterfall и Agile уместно на более высоком уровне, то есть на уровне разработки большой части системы, а не конкретной фичи.
Я Agile и Waterfall воспринимаю очень hi-level. (на прошлой КРИ об этом говорил — посмотрите ссылку в этой статье).
Agile и Waterfall для меня, подчеркну — для меня, это то, как вы считаете вам лучше достигать эффективности —
1.Agile. «быстро и почти без процесса сделать маленькую штуку крутым челом, и затем с заказчиком который рядом итеративно довести до релиза» или
2.Waterfall "_очень_ хорошо и долго думать, 2 дня думать, за 1 день и _1_ итерацию реализовать, не особо важно чтобы чувак был крутой или чтоб заказчик был рядом".
Есть разные задачи, разные люди и команды, когда нужно применять разные подходы.
Что бы вы не выбрали, ваши плюсы это одновременно и ваши минусы, в Agile ваш минус это бОльшее количество итераций, в Waterfall подходе — вы вероятно много думаете где можно было б не думать, вы тяжелее отходите от плана.
Есть задачи когда вы не сможете применить Agile подход, есть задачи когда вы не сможете применить Waterfall подход.
Есть команды и заказчики с которыми вы не сможете применить Agile подход как бы вы не стремились, тоже самое с Waterfall-ом.
Любой проект это всегда Waterfall hi-level, уж не знаю, понимает это кто-нибудь или нет. Любой проект состоит из последовательности больших жестких этапов (concept, preprod, production, post-production), а это Waterfall.
Agile, итерации — оно внутри этапов. Это MSF модель. И она правильная.
Я это всё к чему — очень опасно податься хайпу относительно Agile. Agile это безусловно правильные идеи. Просто не нужно считать что всё остальное это отстой. Нужно понимать что как и почему работает, глубоко, замечу, нужно понимать. Нужно выбирать то что работает конкретно для вас, для вашей команды, для вашей текущей задачи, для вашего заказчика и его текущего настроения (да, даже так бывает!).
Ну и зануда же я :)
Agile и Waterfall для меня, подчеркну — для меня, это то, как вы считаете вам лучше достигать эффективности —
1.Agile. «быстро и почти без процесса сделать маленькую штуку крутым челом, и затем с заказчиком который рядом итеративно довести до релиза» или
2.Waterfall "_очень_ хорошо и долго думать, 2 дня думать, за 1 день и _1_ итерацию реализовать, не особо важно чтобы чувак был крутой или чтоб заказчик был рядом".
Есть разные задачи, разные люди и команды, когда нужно применять разные подходы.
Что бы вы не выбрали, ваши плюсы это одновременно и ваши минусы, в Agile ваш минус это бОльшее количество итераций, в Waterfall подходе — вы вероятно много думаете где можно было б не думать, вы тяжелее отходите от плана.
Есть задачи когда вы не сможете применить Agile подход, есть задачи когда вы не сможете применить Waterfall подход.
Есть команды и заказчики с которыми вы не сможете применить Agile подход как бы вы не стремились, тоже самое с Waterfall-ом.
Любой проект это всегда Waterfall hi-level, уж не знаю, понимает это кто-нибудь или нет. Любой проект состоит из последовательности больших жестких этапов (concept, preprod, production, post-production), а это Waterfall.
Agile, итерации — оно внутри этапов. Это MSF модель. И она правильная.
Я это всё к чему — очень опасно податься хайпу относительно Agile. Agile это безусловно правильные идеи. Просто не нужно считать что всё остальное это отстой. Нужно понимать что как и почему работает, глубоко, замечу, нужно понимать. Нужно выбирать то что работает конкретно для вас, для вашей команды, для вашей текущей задачи, для вашего заказчика и его текущего настроения (да, даже так бывает!).
Ну и зануда же я :)
Большее количество итераций в Agile — это совсем не минус, а то ради чего это все было задумано.
Для сравнения, используя Waterfall на годовом проекте любая ошибка может стоить еще одного года разработки. Изменения, которые накопились в голове у заказчика, будут реализованы только в следующем году, иначе вы сорвете текущий план. Чтобы этого избежать как раз и нужно использовать большое количество итераций с целью повышения прозрачности разработки и получения сходящегося к цели процесса.
Полностью согласен с тем, что всему свое место. Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Что касается MSF, то не вижу тут какого-то открытия. Прежде чем что-то делать, нужно понять что, подготовиться, провести исследования. После того как выполнена основная работа, можно заняться вопросами маркетинга, продажами и т.п.
Тут важно то, что методология подбирается под проект, условия и команду, думаю это ни для кого не открытие.
Для сравнения, используя Waterfall на годовом проекте любая ошибка может стоить еще одного года разработки. Изменения, которые накопились в голове у заказчика, будут реализованы только в следующем году, иначе вы сорвете текущий план. Чтобы этого избежать как раз и нужно использовать большое количество итераций с целью повышения прозрачности разработки и получения сходящегося к цели процесса.
Полностью согласен с тем, что всему свое место. Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Что касается MSF, то не вижу тут какого-то открытия. Прежде чем что-то делать, нужно понять что, подготовиться, провести исследования. После того как выполнена основная работа, можно заняться вопросами маркетинга, продажами и т.п.
Тут важно то, что методология подбирается под проект, условия и команду, думаю это ни для кого не открытие.
Евгений, спасибо за отзыв.
Можете четче сформулировать в чем мы с вами расходимся во мнениях?
Мне просто кажется что позиции наши очень близки.
Мы оба с вами считаем что каждому своё место.
>> Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Перечитайте статью, я говорил что мы применяли Agile там где Waterfall подход сработал бы лучше.
Можете четче сформулировать в чем мы с вами расходимся во мнениях?
Мне просто кажется что позиции наши очень близки.
Мы оба с вами считаем что каждому своё место.
>> Но не понимаю зачем говорить, что Agile ацтой там где его и не имеет смысла применять?
Перечитайте статью, я говорил что мы применяли Agile там где Waterfall подход сработал бы лучше.
Судя по описанному, то что у вам происходило, было не совсем Agile, использование этого магического слова не отменяет необходимости думать и проектировать. А то что вы называете Waterfall — и есть нормальный подход к разработке — анализ, проектирование, разработка, тестирование.
Сакральный смысл Agile в том и состоит, что каждая итерация — это маленький Waterfall с законченной фичей как результат, и поэтому если вы ошиблись на стадии анализа, вы потеряли только 1 итерацию, а не про---ли весь проект как при большом Waterfall-e.
Почитайте еще МакКоннела, там об этом хорошо написано.
Сакральный смысл Agile в том и состоит, что каждая итерация — это маленький Waterfall с законченной фичей как результат, и поэтому если вы ошиблись на стадии анализа, вы потеряли только 1 итерацию, а не про---ли весь проект как при большом Waterfall-e.
Почитайте еще МакКоннела, там об этом хорошо написано.
В слово «гуро» я вкладываю то что обычно понимают под этим люди, «крутого чувака».
Спасибо за ссылку, интересно!
Спасибо за ссылку, интересно!
«крутой чувак» — это гурУ.
«Гуру, в строгом смысле, является не учителем, передающим какую-либо информацию, а тем, кто направляет и питает Пробуждение ученика. Часто словом «гуру» называют профессионалов, виртуозов, мастеров своего дела.»
ru.wikipedia.org/wiki/%D0%93%D1%83%D1%80%D1%83
ru.wikipedia.org/wiki/%D0%93%D1%83%D1%80%D1%83
по-моему всем уже насрать на что то игра — должна быть в первую очередь игрой. И вопрос «что» всегда должен быть основнопологающим над «как». Собственно, «как» появляется из опыта. Сделать без этого опыта то что задумывалось изначально — анрил.
Кстати Идеальный шторм фильм отличный. Его нужно показывать в обучающих целях для небольших команд в любой сфере деятельности.
Во первых, что за игра?
Во вторых, много воды и ничего конкретного. У меня сложилось впечатление, что ваши проблемы были организационного характера и никак не связаны с профессиональными качествами разработчиков. А обилие иностранных терминов также мешает восприятию материала.
Во вторых, много воды и ничего конкретного. У меня сложилось впечатление, что ваши проблемы были организационного характера и никак не связаны с профессиональными качествами разработчиков. А обилие иностранных терминов также мешает восприятию материала.
>> У меня сложилось впечатление, что ваши проблемы были организационного характера и
>> никак не связаны с профессиональными качествами разработчиков.
Блог называется «Управление проектами». Что странного? :)
>> А обилие иностранных терминов также мешает восприятию материала.
В первый раз читаете подобный материал? Обилие этих терминов вполне обьяснимо.
>> никак не связаны с профессиональными качествами разработчиков.
Блог называется «Управление проектами». Что странного? :)
>> А обилие иностранных терминов также мешает восприятию материала.
В первый раз читаете подобный материал? Обилие этих терминов вполне обьяснимо.
а это вообще характерно ыы
Что за игра — пока не могу сказать. Скажу через месяц — другой.
— 3 области ошибок
— много организационных ошибок
— ставка на молодую команду
— удаленность core team
+ всё то, что я писал выше.
— 3 области ошибок
— много организационных ошибок
— ставка на молодую команду
— удаленность core team
+ всё то, что я писал выше.
А «Keep it Simple» разве не из семейства Agile? Вроде, это XP.
А кто еще заметил, что последние месяцы Хабрахабр так и пестрит классными статьями, а ныть «Хабр уже не тот» все перестали начисто?
Такие статьи просто заставляют снова погрузиться в мир геймдева, хоть и не профессиональный, но все же.
Хочется назад в геймдев? :)
Поясните,
Мир не профессионального геймдев в смысле что мы за это не получаем денег (мы их получаем :) ), или в смысле что нам далеко до профи (с этим то я согласен, писал в статье что удивительно что нас не уволили — вероятно других нет)?
Поясните,
Мир не профессионального геймдев в смысле что мы за это не получаем денег (мы их получаем :) ), или в смысле что нам далеко до профи (с этим то я согласен, писал в статье что удивительно что нас не уволили — вероятно других нет)?
Я имел ввиду, что возникает желание снова начать изучение графических движков, принципов содания игр, и попыток создать свой мегавелосипед. Но увы, когда реально начинаешь оценивать свои силы, весь энтузиазм заканчивается и приходится с этим завязывать. Но вскоре, читаешь какой-нибудь интересный постмортем и все начинает повторяться. Вроде бы так.
Классическая часть — приходит новый тим лид программист и говорит, что нужно все переписать :))) В вашем случае это привело, очевидно, к лучшим результатам, но могло дать и другой эффект.
Не совсем. Его ошибка была в том что он так _не_ поступил. Несколько недель он был на проекте и НЕ переписывал код, хотя нужно придти, посмотреть на код пару дней, что-то попробовать сделать, и сразу код выкинуть. Это был код «быстрого» прототипа который никогда не рефакторился.
В целом конечно с вами согласен.
Это типичная ситуация :)
В целом конечно с вами согласен.
Это типичная ситуация :)
«Совершенный код» надо было сразу читать и ещё кое-какие книжки.
Читать и перечитывать раз в год!!!
А какие еще книжки еще?
Не то чтобы я не в теме, просто интересен ваш список.
А какие еще книжки еще?
Не то чтобы я не в теме, просто интересен ваш список.
Другие книжки зависят от того какая стоит задача. «Совершенный код» это же универсальная книга по проектированию и кодированию программ на разных языках и платформах. В ней, кстати, в каждой главе указаны какие конкретно книги нужно читать, чтобы углубиться в тему по разбираемому вопросу.
А так можно называть разное. Одним нужно проектировать GUI, другим работать с базами данных, третьим с математикой, завязанной на графику, физику или ещё что. Плюс поправка на платформу и язык. Сейчас из интернета можно накачать очень множество книг, руководств и прочих полезных материалов. Всё это меняет мировозрение не в меньшей степени, чем «Совершенный код».
От себя бы я добавил, что в программировании очень важно знать, что хочешь получить, нежели как это получить. Так как программисты очень часто усиливают второе умение, забывая о первом. И это в конечном итоге выливается вот в такие вот топики.
А так можно называть разное. Одним нужно проектировать GUI, другим работать с базами данных, третьим с математикой, завязанной на графику, физику или ещё что. Плюс поправка на платформу и язык. Сейчас из интернета можно накачать очень множество книг, руководств и прочих полезных материалов. Всё это меняет мировозрение не в меньшей степени, чем «Совершенный код».
От себя бы я добавил, что в программировании очень важно знать, что хочешь получить, нежели как это получить. Так как программисты очень часто усиливают второе умение, забывая о первом. И это в конечном итоге выливается вот в такие вот топики.
Автор начитался книг про трагедии в проектах и представил себя героем одного из них.
Еще забавляет когда человек, начинает всюду в свою речь вставлять всякие «это не есть issue и наш vision не привел к трагической death в итоге мы стали winnera-ми». Моя клиентка, как-то раз сказала про подобного персонажа: «наш технический директор такой умный, только он так быстро говорит и ничего не понятно».
Мысль в том, что можно работать не играя в игры, и разговаривать на чистом и понятном языке.
Еще забавляет когда человек, начинает всюду в свою речь вставлять всякие «это не есть issue и наш vision не привел к трагической death в итоге мы стали winnera-ми». Моя клиентка, как-то раз сказала про подобного персонажа: «наш технический директор такой умный, только он так быстро говорит и ничего не понятно».
Мысль в том, что можно работать не играя в игры, и разговаривать на чистом и понятном языке.
действительно, статья на каком-то арго написана :(
вообще, такое калькирование слов свойственно для покоренных народов, которые находятся под культурным гнетом народа-победителя.
хотя на моей прошлой работе также говорили: проперти-пропертя-пропертей и т.п.
или у Задорнова когда0то было: «Вам чиза наслайсать или одним писом»
вообще, такое калькирование слов свойственно для покоренных народов, которые находятся под культурным гнетом народа-победителя.
хотя на моей прошлой работе также говорили: проперти-пропертя-пропертей и т.п.
или у Задорнова когда0то было: «Вам чиза наслайсать или одним писом»
Спасибо за мнение.
Вероятно, просто этот текст написал не для вас.
Ничего страшного в этом нету )
Вероятно, просто этот текст написал не для вас.
Ничего страшного в этом нету )
Читать интересно и автору спасибо, но действительно мозг аж наизнанку вывернуло от обилия слов, которым вполне можно найти адекватный аналог в родном языке.
Прикиньте. Я спрашиваю у команды — ну как вам постмортем?
И слышу ответы
— ну вроде ничего, просмотрел мельком
— много букв, я не читал
— гхм!, у меня не было на это времени!!! (это говорит сча наш самый крутой художник проекта в 21:20, в субботу, мы с ним вдвоем остались на офисе, и у нас осталось 1.5 часа до deadline по сабмишну в Verizon, срочно доделываем промо флешку, вот она жизнь!!! )
чОрт, я не специально!
И слышу ответы
— ну вроде ничего, просмотрел мельком
— много букв, я не читал
— гхм!, у меня не было на это времени!!! (это говорит сча наш самый крутой художник проекта в 21:20, в субботу, мы с ним вдвоем остались на офисе, и у нас осталось 1.5 часа до deadline по сабмишну в Verizon, срочно доделываем промо флешку, вот она жизнь!!! )
чОрт, я не специально!
Какие, блять, знакомые ощущения.
На самом деле человек очень гордится проделанной работой и его распирает поделиться! Это очень классное чувство — удовлетворение от пройденного пути и гордость за то что получилось! Удачи с выпуском! ;)
Честнагря, когда читаешь такие статьи, становится непонятно что вообще делают менеджеры и дезигнеры в разработках игр? Программеры пишут код, думают над архитектурой — это понятно. Художники рисуют — это понятно. Ну стоит над ними главный архитектор и идеолог. Неужели мало?
Читаю статьи на сайте КРИ.
«Мы сделали игру (какую-то стратегию), и начали тестирование на пользователях. И тут выяснилось, что наш интерфейс пользователи не понимают»! Ёпт а о чем вы раньше думали, спрашивается?
«Пользователь первые пол-часа не мог въехать как управлять игрой. Оказывается, он не понял, что чтобы главный персонаж начал двигаться, его надо вначале активизировать». Конечно, это же главный персонаж, он сразу виден на экране и пользователь ожидает, что его активизировать ненадо.
«Другие пользователи тоже не отличались сообразительностью, и не могли начать играть в нашу игру». О чем думал дезигнер интерфейса, что для него это сюрприз? Что делают эти люди в командах разработчиков игр?
А вообще, после прочтения таких статей, понимаешь, какой кризис в игровой индустрии. Деньги уработали индустрию в какую-то дикую область контролируемых рисков. Играми занимаются случайные люди, которые просто умеют что-то делать. Появляются какие-то методики и техники со своей терминологией, которые должны формализовать творческий поиск и засунуть всё в понятные менеджерам рамки. Даже мощные идеологически выдержанные проектировщики типа Кранха, вместо того чтобы выпускать хитовые проекты, и те сгибаются под рынком и выпускают поделия чуть выше среднего уровня. Одно превращение концепта Периметра чего стоило — вместо «новой вехи» получили обычную RTS.
Пипец кароче, лучшеб не читал про эти потуги, тошно становится. Тут не гордиться за то что получилось, а плакать нужно. Хотя, статья важна именно этим — хороший пример состояния дел в мозгах и в отрасли.
Читаю статьи на сайте КРИ.
«Мы сделали игру (какую-то стратегию), и начали тестирование на пользователях. И тут выяснилось, что наш интерфейс пользователи не понимают»! Ёпт а о чем вы раньше думали, спрашивается?
«Пользователь первые пол-часа не мог въехать как управлять игрой. Оказывается, он не понял, что чтобы главный персонаж начал двигаться, его надо вначале активизировать». Конечно, это же главный персонаж, он сразу виден на экране и пользователь ожидает, что его активизировать ненадо.
«Другие пользователи тоже не отличались сообразительностью, и не могли начать играть в нашу игру». О чем думал дезигнер интерфейса, что для него это сюрприз? Что делают эти люди в командах разработчиков игр?
А вообще, после прочтения таких статей, понимаешь, какой кризис в игровой индустрии. Деньги уработали индустрию в какую-то дикую область контролируемых рисков. Играми занимаются случайные люди, которые просто умеют что-то делать. Появляются какие-то методики и техники со своей терминологией, которые должны формализовать творческий поиск и засунуть всё в понятные менеджерам рамки. Даже мощные идеологически выдержанные проектировщики типа Кранха, вместо того чтобы выпускать хитовые проекты, и те сгибаются под рынком и выпускают поделия чуть выше среднего уровня. Одно превращение концепта Периметра чего стоило — вместо «новой вехи» получили обычную RTS.
Пипец кароче, лучшеб не читал про эти потуги, тошно становится. Тут не гордиться за то что получилось, а плакать нужно. Хотя, статья важна именно этим — хороший пример состояния дел в мозгах и в отрасли.
Спасибо за отзыв. Да в геймдеве дела, мягко говоря не не очень хороши.
В целом в IT всё лучше огранизовано.
В геймдеве слишком много неучей и неумек.
Но и игры это очень сложный софт, сложные проекты, это тоже нужно понимать.
Возьмите WOW или Аллоды Онлайн, это _очень_ сложные проекты.
А откуда взяться профи, если гейм-дизайну у нас в универах еще не учат?
Тоже самое, но в меньшей степени, про менеджеров.
Нужно жить с теми людьми что есть, учиться самому, учить других.
В целом в IT всё лучше огранизовано.
В геймдеве слишком много неучей и неумек.
Но и игры это очень сложный софт, сложные проекты, это тоже нужно понимать.
Возьмите WOW или Аллоды Онлайн, это _очень_ сложные проекты.
А откуда взяться профи, если гейм-дизайну у нас в универах еще не учат?
Тоже самое, но в меньшей степени, про менеджеров.
Нужно жить с теми людьми что есть, учиться самому, учить других.
«дела в геймдве не не очень хороши» следует читать «дела в геймдеве не очень хороши»
Когда я учился в колледже (10-11 классы) ВКИ НГУ, то там пол года был так называемый вводный проект на котором все аспекты разработки игр освещались (ну или почти все)… правдо было это 8 лет назад, не знаю как сейчас дела обстоят.
А вот в США и Европе геймдизайну учат в специальных колледжах и университетах.
А вот в США и Европе геймдизайну учат в специальных колледжах и университетах.
О как интересно.
Подробнее расскажите, какие именно аспекты освещались?
Как курс назывался?
Интересует прежде всего единственная уникальная профессия в геймдеве — гейм-дизайн.
Какие аспекты гейм-дизайна вам рассказывали в 10-11 классах 8 лет назад?
В США и Европе учат да, это круто. Даже кто-то что-то у нас пытается изобразить.
Подробнее расскажите, какие именно аспекты освещались?
Как курс назывался?
Интересует прежде всего единственная уникальная профессия в геймдеве — гейм-дизайн.
Какие аспекты гейм-дизайна вам рассказывали в 10-11 классах 8 лет назад?
В США и Европе учат да, это круто. Даже кто-то что-то у нас пытается изобразить.
Спасибо за статью.
__
Только Agile и Waterfall? RUP с кучей модификаций совсем не катит?
__
Только Agile и Waterfall? RUP с кучей модификаций совсем не катит?
Agile, кстати, какой именно? Scrum?
Спасибо вам!
— Я писал выше что Agile и Waterfall я воспринимаю hi-level, как вы достигаете эффективности.
Вариаций методологий тьма, но это мало влияет на то что мы обсуждаем.
— Я писал выше что Agile и Waterfall я воспринимаю hi-level, как вы достигаете эффективности.
Вариаций методологий тьма, но это мало влияет на то что мы обсуждаем.
вы пишете о выборе между водопадом и гибкими методологиями, так, как будто кроме них ничего нет. хотя весь мир живет по rup или cmm.
:-)
:-)
Перечитайте, для меня это две разных hi-level идеи как достигать эффективность по конкретным задачам. других принципиально разных идей я не знаю.
rup,cmm,xp,scrum — все что угодно, это конкретные реализации и они нам честно говоря мало интересны,
Ибо в IT — наша методология эта та, которая хорошо работает для нашего проекта команды компании и заказчика.
rup,cmm,xp,scrum — все что угодно, это конкретные реализации и они нам честно говоря мало интересны,
Ибо в IT — наша методология эта та, которая хорошо работает для нашего проекта команды компании и заказчика.
>других принципиально разных идей я не знаю.
может в этом проблема? вообще говоря, как директор it компании могу сказать, что «опытный пм» в 26 лет это нонсенс. так что, в целом, ничего удивительного.
может в этом проблема? вообще говоря, как директор it компании могу сказать, что «опытный пм» в 26 лет это нонсенс. так что, в целом, ничего удивительного.
не ошибается, кто ничего не делает
habrahabr.ru/blogs/pm/51929/#comment_1377660
это кстати не вполне верно
«принципы agile»
Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им — они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром — непосредственное общение.
Работающее ПО — главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота — искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.
основной признаки мотивированная самоорганизующаяся команда. положа руку на сердце — она у вас была? и это эжайл? или все-таки путаница в терминах?
это кстати не вполне верно
«принципы agile»
Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПО.
Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.
Выполняйте частые поставки работающего ПО. При этом продолжительность каждой итерации должна быть от пары недель до пары месяцев, предпочтение отдается коротким интервалам.
Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
Привлекайте для работы над проектом мотивированных людей. Создайте для них все условия, окажите поддержку во всем, что необходимо, и доверьтесь им — они выполнят работу.
Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром — непосредственное общение.
Работающее ПО — главный индикатор продвижения проекта.
Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.
Важна простота — искусство увеличения объема работ, которых удалось избежать.
Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами.
Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПО.
основной признаки мотивированная самоорганизующаяся команда. положа руку на сердце — она у вас была? и это эжайл? или все-таки путаница в терминах?
То как я hi-level понимаю Agile это, повторюсь (см так же выше),
Agile. «быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
Выше я привел своё hi-level понимание Agile,
Если это моё понимание Agile и те выводы что я делаю, кажутся вам (или кому-то) полезными — я рад. Согласен с вами, что обсуждать кто как понимает термины большого смысла нету.
Я не уверен что текст который вы написали противоречит как-то моему тексту, или моему пониманию Agile
Спасибо за отзыв!
Agile. «быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
Выше я привел своё hi-level понимание Agile,
Если это моё понимание Agile и те выводы что я делаю, кажутся вам (или кому-то) полезными — я рад. Согласен с вами, что обсуждать кто как понимает термины большого смысла нету.
Я не уверен что текст который вы написали противоречит как-то моему тексту, или моему пониманию Agile
Спасибо за отзыв!
>> вообще говоря, как директор it компании могу сказать
Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.
Буду рад если вы, более опытный специалист, укажите мне на другие hi-level идеи. Я их действительно не знаю.
Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.
Буду рад если вы, более опытный специалист, укажите мне на другие hi-level идеи. Я их действительно не знаю.
основная проблема (не Ваша, а вообще )) к сожалению), что люди что то слышали про эжайл, пытаются применить какие -то методологии, а потом говорят «ничего не работает»
я поэтому спрашивал по конкретную реализацию.
К примеру, нельзя применять XP частично, потому что осутствие документации заменяет общение в одной комнате, а доп тестрование — парное программирование. Отмените одно — все посыпится. В Вашем случае хорошо мог работать, вероятно, FDD. Он представляет собой иерархическую схему отвтевенности, в отличии от сетвой в XP (что у Вас вообще не могло работать в распределенной команде) или Scrum.
Многие беды происходят от путаницы в терминах. Ваши hi-level идеи меня вообще слегка шокируют. Я Вам привел основные постулаты Aglie — т.н. Манифест Гибкой Разработки, в котором черным по белому написано о важности команды, Вы в статье пишете о том, что люди «не понимали и не принмали» и после этого удивляетесь провалу.
Agile — это не анархия.
>«быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
А что, в RUP по-другому???? Это основа всех итеративных процессов разработки.
На хабре существует тайное общество моих поклонников, минусующих все мои комментарии ))), очевидно, им претит идея профессионализма как такового, которую я пытаюсь отстаивать, но тем не менее, прежде чем все смешивать в одно и делить на две неравные кучи «эжайл» и «уотефол» может стоит разобраться в сущности подходов. Почему они такие, что решают и где нужны?
я поэтому спрашивал по конкретную реализацию.
К примеру, нельзя применять XP частично, потому что осутствие документации заменяет общение в одной комнате, а доп тестрование — парное программирование. Отмените одно — все посыпится. В Вашем случае хорошо мог работать, вероятно, FDD. Он представляет собой иерархическую схему отвтевенности, в отличии от сетвой в XP (что у Вас вообще не могло работать в распределенной команде) или Scrum.
Многие беды происходят от путаницы в терминах. Ваши hi-level идеи меня вообще слегка шокируют. Я Вам привел основные постулаты Aglie — т.н. Манифест Гибкой Разработки, в котором черным по белому написано о важности команды, Вы в статье пишете о том, что люди «не понимали и не принмали» и после этого удивляетесь провалу.
Agile — это не анархия.
>«быстро и почти без процесса сделать маленькую штуку крутыми челами, и затем с заказчиком который рядом итеративно довести до релиза»
А что, в RUP по-другому???? Это основа всех итеративных процессов разработки.
На хабре существует тайное общество моих поклонников, минусующих все мои комментарии ))), очевидно, им претит идея профессионализма как такового, которую я пытаюсь отстаивать, но тем не менее, прежде чем все смешивать в одно и делить на две неравные кучи «эжайл» и «уотефол» может стоит разобраться в сущности подходов. Почему они такие, что решают и где нужны?
p.s.
Мне, кстати, нравятся Ваши посты. Еще раз, спасибо.
Мне, кстати, нравятся Ваши посты. Еще раз, спасибо.
p.p.s.
посмотрел ваш жж.
вы же все это прекрасно и сами знаете )) на личном опыте.
посмотрел ваш жж.
вы же все это прекрасно и сами знаете )) на личном опыте.
>Как директор ит компании и пм с 5+ летним опытом согласен с вами что «опытный» пм в 26 лет это нонсенс.
кстати, 5 лет — это уже хороший опыт, но тогда я вам сочувствую, потому, что руководить в 21 — после института, без реального опыта работы, это наверняка было весьма тяжело
кстати, 5 лет — это уже хороший опыт, но тогда я вам сочувствую, потому, что руководить в 21 — после института, без реального опыта работы, это наверняка было весьма тяжело
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальный шторм. Постмортем неанонсированного проекта.