>> вверх списка поместить и получить выполненную задачу уже очень скоро.
Чем это отличается от бэклога в scrum?
Бэклог в скраме трогается только при планировании нового спринта и если туда что-то помещается, то в работу это пойдет только в след. спринте. А если спринт — 1 месяц, то это ой как нескоро. Да и 2 недели тоже.
>>В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Если я правильно понимаю, то это — не очень хорошо и вряд ли позитивно сказывается на качестве.
В целом — да. Но там по-другому нельзя — слишком много креатива, проб и ошибок.
Или имеется в виду, что в ваших терминах новая != непредвиденная?
Да, новая != непредвиденная. Непредвиденные задачи — это когда у тебя распланирован спринт и все заполнено и вдруг приходит новая срочная задача. А ты сопротивляешься ей, т.к. внутри спринта задачи нельзя новые добавлять.
В Канбан нет непредвиденных задач, т.к. никто не планирует вперед. Задача обсуждается и принимается в работу только когда для нее появляется место. Поэтому если появляется новая задача — ее приоритизирует product owner и помещает в буфер задач, а оттуда она уже будет взята в разработку, когда команда доберется. А если приоритет очень высок, то можно и вверх списка поместить и получить выполненную задачу уже очень скоро.
Имхо если 50% непредвиденных — то это уже даже не управлятор рисками дал сбой, а в понимании задачи командой что-то не то, или команда представляет из себя не то, что думает лид. И методология тут уже ИМХО влияет мало.
В техподдержке крупной системы только так люди и работают — каждый день что-то новое :)
В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Да, так и было. На спринт планнинге мы не планировали конкретные работы, а просто общались с product owner-ами и выясняли, сколько мы должны времени потратить на работу на каждого из них (т.к. у нас было несколько product owner-ов с разными целями и задачами).
Далее каждый из них имел свой бэклог с приоритизированными задачами и мы просто брали оттуда задачи, когда заканчивали очередную и делали их. Планирования сроков никакого не было — только обсуждение технической стороны задачи, когда ее берешь.
Опять же повторюсь — если команда работает и хочет работать хорошо, то какое еще планирование нужно? Если в бэклоге 50 задач, то мы должны все их сесть и оценить? Или мы должны, как в Scrum, оценивать только на 2 недели вперед? Так через день придет новый баг и его надо исправлять. В Scrum это решается планированием «непредвиденных задач», но если непредвиденных — 50%, то это уже глупо становится.
Вы похоже не поняли идею применения Канбан к IT. Конвеер — это в TPS (toyota production system), а в IT Канбан совсем о другом — о разработке новых больших фич (ММФ) как можно быстрее. Никакого конвеера нет и в помине.
Как данная методология решает основной вопросы на уровне топ-менеджмента: Когда в продакшене будет следующая стабильная версия системы?
А как любая другая методология решает этот вопрос? Фактически никак — ставится срок на основе каких-то предварительных оценок и проект движется к этому сроку. Что успели сделать — то входит в состав проекта. Что не успели — не входит, либо срок передвигается.
Какую методологию не используй, точно спрогнозировать вначале не сможешь. Можно только буферы задать побольше, чтобы подстраховаться.
В Канбане тоже самое, только измерение времени идет по скорости разработки одной задачи. Если на проект есть 100 задач и мы знаем, что команда в среднем делает задачу за неделю и параллельно может делать до 5 задач, то можем считать, что через 20 недель все будет готово.
— Методология подходит только для проектов с дедлайнами типа «when it's done» (таких меньшинство)
Не только. Но для работы над проектами с жестким дедлайном и жестким набором фич эта методология плохо подходит — факт.
— Оценка временнЫх факторов решения задач все равно присутствует в неявной форме в ежедневной работе менеджера
Конечно присутствует. Иначе зачем мерять время на выполнение одной задачи?
Менеджер (product owner) по-прежнему должен общаться с маркетингом и другими заинтересованными лицами и должен следить за конечным сроком. Инструменты для этого в Канбан есть — это время на выполнения 1 задачи и число задач, выстроенных по приоритетам.
2) Частично согласен, что кол-во параллельных задач в работе определяется кол-вом программистов. Частично, потому что это кол-во еще определяется индивидуальными качествами программистов, маркетинговыми потребностями, техническими взаимосвязями в задачах.
Да, ограничение на число параллельно выполняемых задач не жесткое и зависит от команды и других условий. Команда вольна сама менять эти ограничения, если видит, что может работать эффективнее, увеличив или снизив их.
В моем понимании, контроль — это _управляемость_ процессом разработки, т.е. возможность направлять его в нужное на данный момент русло.
В моем тоже. И тут Канбан как нельзя лучше подходит к проектам, где изменения происходят очень часто. Например — поддержка (maintenance). Или любая другая разработка, где 2 недели на спринт — это слишком много, т.к. изменения в планы приходится вносить чуть ли не каждый день.
В-общем, если резюмировать — agile с недельными спринтами и оценками задач при планировании более предсказуем для команды, которая уже хотя бы один проект по такой методике имеет за плечами.
Не согласен. Чистый Agile (Scrum) с недельными спринтами будет иметь слишком большой оверхед на поддержку методологии — слишком много «обязательных» артефактов и обсуждений. Хотя опять же все зависит от команды и условий проекта, так что тут нет общего решения.
Я не говорю про TPS, я говорю про Канбан. Никто не пытается перенести всю систему работы в Тойоте в IT — это невозможно и не нужно. Да и само слово «Канбан» взято из TPS скорее потому, что красиво звучит :)
Основа у Канбан та же, что и у TPS — уменьшение work in progress, но это и всё. Что еще взято из TPS?
Канбан — это просто адаптация хорошей идеи к реалиям разработки ПО.
>> если нет временнных отметок, как тогда продаются эти проекты?
А как временные отметки (итерации, спринты) связаны с продажей? Итерации в Scrum или XP — это просто квант работы команды. А проект содержит результат работы нескольких команд и в течение нескольких итераций.
В случае с Канбан никаких итераций нет — есть задачи. Они постепенно выполняются, проект наполняется фичами. В какой-то момент менеджер или product owner может решить, что проект достаточно хорош и готов к релизу и «продать» его.
Либо же просто ждать, пока самые важные фичи не будут выполнены.
Так оно обычно и получается — дял реально гибких разработчиков даже Scrum недостаточно гибок, да и не для каждой работы он подходит, так что начинают его упрощать. А тут уже и Канбан.
Но основная идея Канбана — ограничивать число «работы в данный момент» на каждом этапе разработки. Без этого Канбан -не совсем Канбан.
У нас и доски, и кофемашины, и спортзал, и чего только нет :)
Если методология подходит команде и команда работает лучше, то она приносит больше денег фирме, а значит фирма тратит больше денег на всякие полезные мелочи.
>> Какие из ныне существующих MMO(RP)G Вам видятся наиболее успешными? Ну, не считая World of Warcraft.
Я не очень-то силен в ММО, предпочитаю не трогать то, что вызывает привыкание :)
Но есть где-то в интернете рейтинги ММО по числу юзеров, денег и т.п. — можно найти.
Используются для чего?
Сам код пишется на С++.
Интерфейс обычно на каком-то спец. языке для интерфейса или на Flash.
Скрипты для миссий и т.п. — на Java, Lua, Python, C# — на чем душе угодно :)
Некоторые даже всю логику игры на скриптовых языках пишут.
«Тонкий» и с «хитростями» — это его и убивает. Слишком низкий уровень, слишком мало готовых компонентов по сравнению с другими языками, слишком высока вероятность ненужной ошибки и т.п.
Да, безусловно.
У молодых команд небольших есть преимущество — на них не висят большие обязательства (по зарплате, по офису, связи с другими компаниями и т.п.), поэтому можно экспериментировать. Нужны простые интересные идеи и их можно реализовывать на всевозможных платформах:
социальные сети, онлайн игры наподобии armorgames.com, казуальные игры. Причем из одной идеи можно сделать сразу несколько реализаций и может даже немного заработать на этом.
А дальше — копить опыт и думать.
>>Apple Store еще ниша?
Ну уверен, что для начинающих это еще ниша. Слишком большая конкуренция с «большими» компаниями.
>> Принимают ли разработчики качественных коммерческих игр участие в судьбах игровых open source проектов (в
>> свободное время или же после смены рода деятельности)?
За всех не скажу, но кто-то принимает. У меня в команде были такие. В основном это люди, сидящие на Linux — для Linux они и пишут Open Source игры.
>> Почему ни у одной компании-разработчика (по крайней мере из мне известных) не возникает желания раскрыть
>> все внутренности некогда выпущенной игры, когда прошло, к примеру, уже лет по 5 и более с момента релиза и
>> все продажи сошли на нет?
Это не совсем так. Вся серия Quake доступна в виде исходников. Другие игры тоже можно найти. Причем вроде как из этих исходников даже можно сделать свою игру и продавать её, но я не уверен, что я правильно помню лицензию.
Но в целом — да, не открывают код. Все считают, что имеют какие-то ноу-хау и чего-то боятся.
Я вообще ратовал за большую открытость разработчиков, а то не только код не открывают, но даже с другими разработчиками боятся общаться, чтобы не дай бог какой секрет не рассказать.
>> Какое направление игровой индустрии вам кажется более привлекательным (с точки зрения разработки и
>> окупаемости) на сегодняшний день: традиционные «оффлайновые» или сугубо онлайновые игры (MMOG)? Под
>> какие платформы: Windows, Windows+*NIX, консоли, мобильные устройства?
Большие MMOG прибыльны при вложении очень больших средств. Без вложений — нет. Есть еще браузерки и т.п. — там не нужны почти вложения, но сейчас рынок переполнен. Офлайновые всегда были попроще в плане продаж и туда легче попасть и продать что-то хорошее. Если на консоли, то особенно выгодно.
*nix — невыгодно совершенно.
Мобильные устройства — нужно делать множество очень простых игр, чтобы что-то заработать. 1-ой игрой не заработаешь.
В общем, бизнес очень интересный и сложный — несколько крупнейших компаний имеют 80% прибыли, а все остальные сидят на оставшихся 20%. Чтобы зарабатывать миллионы нужно делать очень качественный продукт, то есть тратить миллионы. А не имея миллионов расчитывать на большие заработки почти невозможно.
Но бывают исключения — например, серия «Космических рейнджеров» и теперь «Kings Bounty».
Чем это отличается от бэклога в scrum?
Бэклог в скраме трогается только при планировании нового спринта и если туда что-то помещается, то в работу это пойдет только в след. спринте. А если спринт — 1 месяц, то это ой как нескоро. Да и 2 недели тоже.
>>В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Если я правильно понимаю, то это — не очень хорошо и вряд ли позитивно сказывается на качестве.
В целом — да. Но там по-другому нельзя — слишком много креатива, проб и ошибок.
Да, новая != непредвиденная. Непредвиденные задачи — это когда у тебя распланирован спринт и все заполнено и вдруг приходит новая срочная задача. А ты сопротивляешься ей, т.к. внутри спринта задачи нельзя новые добавлять.
Имхо если 50% непредвиденных — то это уже даже не управлятор рисками дал сбой, а в понимании задачи командой что-то не то, или команда представляет из себя не то, что думает лид. И методология тут уже ИМХО влияет мало.
В техподдержке крупной системы только так люди и работают — каждый день что-то новое :)
В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
Далее каждый из них имел свой бэклог с приоритизированными задачами и мы просто брали оттуда задачи, когда заканчивали очередную и делали их. Планирования сроков никакого не было — только обсуждение технической стороны задачи, когда ее берешь.
Опять же повторюсь — если команда работает и хочет работать хорошо, то какое еще планирование нужно? Если в бэклоге 50 задач, то мы должны все их сесть и оценить? Или мы должны, как в Scrum, оценивать только на 2 недели вперед? Так через день придет новый баг и его надо исправлять. В Scrum это решается планированием «непредвиденных задач», но если непредвиденных — 50%, то это уже глупо становится.
А как любая другая методология решает этот вопрос? Фактически никак — ставится срок на основе каких-то предварительных оценок и проект движется к этому сроку. Что успели сделать — то входит в состав проекта. Что не успели — не входит, либо срок передвигается.
Какую методологию не используй, точно спрогнозировать вначале не сможешь. Можно только буферы задать побольше, чтобы подстраховаться.
В Канбане тоже самое, только измерение времени идет по скорости разработки одной задачи. Если на проект есть 100 задач и мы знаем, что команда в среднем делает задачу за неделю и параллельно может делать до 5 задач, то можем считать, что через 20 недель все будет готово.
— Методология подходит только для проектов с дедлайнами типа «when it's done» (таких меньшинство)
Не только. Но для работы над проектами с жестким дедлайном и жестким набором фич эта методология плохо подходит — факт.
— Оценка временнЫх факторов решения задач все равно присутствует в неявной форме в ежедневной работе менеджера
Конечно присутствует. Иначе зачем мерять время на выполнение одной задачи?
Менеджер (product owner) по-прежнему должен общаться с маркетингом и другими заинтересованными лицами и должен следить за конечным сроком. Инструменты для этого в Канбан есть — это время на выполнения 1 задачи и число задач, выстроенных по приоритетам.
2) Частично согласен, что кол-во параллельных задач в работе определяется кол-вом программистов. Частично, потому что это кол-во еще определяется индивидуальными качествами программистов, маркетинговыми потребностями, техническими взаимосвязями в задачах.
Да, ограничение на число параллельно выполняемых задач не жесткое и зависит от команды и других условий. Команда вольна сама менять эти ограничения, если видит, что может работать эффективнее, увеличив или снизив их.
В моем понимании, контроль — это _управляемость_ процессом разработки, т.е. возможность направлять его в нужное на данный момент русло.
В моем тоже. И тут Канбан как нельзя лучше подходит к проектам, где изменения происходят очень часто. Например — поддержка (maintenance). Или любая другая разработка, где 2 недели на спринт — это слишком много, т.к. изменения в планы приходится вносить чуть ли не каждый день.
В-общем, если резюмировать — agile с недельными спринтами и оценками задач при планировании более предсказуем для команды, которая уже хотя бы один проект по такой методике имеет за плечами.
Не согласен. Чистый Agile (Scrum) с недельными спринтами будет иметь слишком большой оверхед на поддержку методологии — слишком много «обязательных» артефактов и обсуждений. Хотя опять же все зависит от команды и условий проекта, так что тут нет общего решения.
Основа у Канбан та же, что и у TPS — уменьшение work in progress, но это и всё. Что еще взято из TPS?
Канбан — это просто адаптация хорошей идеи к реалиям разработки ПО.
А как временные отметки (итерации, спринты) связаны с продажей? Итерации в Scrum или XP — это просто квант работы команды. А проект содержит результат работы нескольких команд и в течение нескольких итераций.
В случае с Канбан никаких итераций нет — есть задачи. Они постепенно выполняются, проект наполняется фичами. В какой-то момент менеджер или product owner может решить, что проект достаточно хорош и готов к релизу и «продать» его.
Либо же просто ждать, пока самые важные фичи не будут выполнены.
Но основная идея Канбана — ограничивать число «работы в данный момент» на каждом этапе разработки. Без этого Канбан -не совсем Канбан.
Если методология подходит команде и команда работает лучше, то она приносит больше денег фирме, а значит фирма тратит больше денег на всякие полезные мелочи.
Я не очень-то силен в ММО, предпочитаю не трогать то, что вызывает привыкание :)
Но есть где-то в интернете рейтинги ММО по числу юзеров, денег и т.п. — можно найти.
Сам код пишется на С++.
Интерфейс обычно на каком-то спец. языке для интерфейса или на Flash.
Скрипты для миссий и т.п. — на Java, Lua, Python, C# — на чем душе угодно :)
Некоторые даже всю логику игры на скриптовых языках пишут.
Но вся база обычно на С++
Да, безусловно.
У молодых команд небольших есть преимущество — на них не висят большие обязательства (по зарплате, по офису, связи с другими компаниями и т.п.), поэтому можно экспериментировать. Нужны простые интересные идеи и их можно реализовывать на всевозможных платформах:
социальные сети, онлайн игры наподобии armorgames.com, казуальные игры. Причем из одной идеи можно сделать сразу несколько реализаций и может даже немного заработать на этом.
А дальше — копить опыт и думать.
>>Apple Store еще ниша?
Ну уверен, что для начинающих это еще ниша. Слишком большая конкуренция с «большими» компаниями.
>> свободное время или же после смены рода деятельности)?
За всех не скажу, но кто-то принимает. У меня в команде были такие. В основном это люди, сидящие на Linux — для Linux они и пишут Open Source игры.
>> Почему ни у одной компании-разработчика (по крайней мере из мне известных) не возникает желания раскрыть
>> все внутренности некогда выпущенной игры, когда прошло, к примеру, уже лет по 5 и более с момента релиза и
>> все продажи сошли на нет?
Это не совсем так. Вся серия Quake доступна в виде исходников. Другие игры тоже можно найти. Причем вроде как из этих исходников даже можно сделать свою игру и продавать её, но я не уверен, что я правильно помню лицензию.
Но в целом — да, не открывают код. Все считают, что имеют какие-то ноу-хау и чего-то боятся.
Я вообще ратовал за большую открытость разработчиков, а то не только код не открывают, но даже с другими разработчиками боятся общаться, чтобы не дай бог какой секрет не рассказать.
>> Какое направление игровой индустрии вам кажется более привлекательным (с точки зрения разработки и
>> окупаемости) на сегодняшний день: традиционные «оффлайновые» или сугубо онлайновые игры (MMOG)? Под
>> какие платформы: Windows, Windows+*NIX, консоли, мобильные устройства?
Большие MMOG прибыльны при вложении очень больших средств. Без вложений — нет. Есть еще браузерки и т.п. — там не нужны почти вложения, но сейчас рынок переполнен. Офлайновые всегда были попроще в плане продаж и туда легче попасть и продать что-то хорошее. Если на консоли, то особенно выгодно.
*nix — невыгодно совершенно.
Мобильные устройства — нужно делать множество очень простых игр, чтобы что-то заработать. 1-ой игрой не заработаешь.
В общем, бизнес очень интересный и сложный — несколько крупнейших компаний имеют 80% прибыли, а все остальные сидят на оставшихся 20%. Чтобы зарабатывать миллионы нужно делать очень качественный продукт, то есть тратить миллионы. А не имея миллионов расчитывать на большие заработки почти невозможно.
Но бывают исключения — например, серия «Космических рейнджеров» и теперь «Kings Bounty».