Oleg bishop3000

12 часов тянент с нашим антивирусом (F-Secure), сам тестировал и оптимизировал :)

Фотка из Хельсингского аквапарка «Серена». Там, чтоли, это уже поставили? В прошлом году не видел.

Все верно вы написали, даже добавить нечего.

>> BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении
>> проектами» постить?

Все равно уже на главной — все прочитают и оттуда и оттуда :)
На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.

А попробуйте «инжиниринг» на русский перевести. «Программотехника» я нашел, но звучит по-советски. Уж лучше «индиниринг».

>> Но ни слова о том, что отсутсвие метрик — залог успеха.

«Залога успеха» в разработке ПО вообще нет и быть не может. А уж называть «залогом успеха» отсутствие чего-то — это глупо было бы.

Странно, может мы разные статьи читали?

Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…

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

Пробую с этим справиться, но пока что таким образом, что product owner-у не отказываю, но людей со старых задач стараюсь не снимать — пытаюсь хэндлить их самостоятельно. То есть как бы есть специальный выделенный человек на «неожиданности».

В классическом Канбан Product Owner должен решить, какую из задач в очереди убрать и куда поместить новую высокоприоритетную. Но он не может ее впихнуть в производство, т.к. только одну может.

У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.

>> Кто будет думать над hi-lvl архитектурой, когда product owner
>> лично назначает приоритеты? Где в данной схеме место
>> тех.лида?

Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.

Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

Значит все-таки не обезьяна :)

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

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

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

Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.

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

Так ли это по сути?
Вы можете рассчитать этот квант и соотношение запланированного к выполненому. Вы можете знать, сколько команда выполнит в следующем спринте, исходя из этих данных.
И это всё!

Что вы знаете про весь проект с этими данными? Ведь чтобы оценить весь проект, надо оценить каждую фичу в проекте, причем довольно точно. Если неточно оценил — грош цена такой оценке и это тоже самое, что и менеджер на коленке бы прикинул, что успеет сделаться, а что нет.
Собственно, гибкая разработка как раз о том, что нифига мы не можем прогнозировать точно и должны быть просто готовы зарелизить тогда, когда надо, а что не успели — отрезать.
Точные прогнозы — это к более тяжелым процессам, а не к agile.

В канбане все тоже самое — есть примерный скоуп проекта и команда его выполняет максимально быстро. product owner следит за скоупом и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну и меняет приоритеты, если что.
Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

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

Ну, если менеджер — обезьяна, то тут и скрам не поможет. Обезьяна все равно скакать вокруг постоянно будет :)

Про рефакторинг — это целый отдельный разговор. Кто-то делает его постоянно про разработке любой фичи, считая, что тронул код — прорефакторь его.
Кто-то выделяет специально время на него — это уже может быть вне канбана. Просто раз в полгода на 2 недели все делают рефакторинг.
А можно и фичу такую завести и назвать ее как-нибудь типа «Улучшение надежности, стабильности и поддерживаемости кода».

С какими, например?
Общий случай — включать их в более крупные фичи.

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

А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.

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

Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.

Приоритеты ставит product owner. И он же должен и фичам сопротивляться — он владелец проекта и он лучше всех остальных должен знать, что хорошо, а что плохо.

А вот еще мои слова, подтверждающие ваши: :)
Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.

Про приоретизацию в трех основных правилах не сказано, да. Наверное потому, что это не задача команды, а задача product owner-а, который является внешней силой.
Про оценку времени сказано в третьем правиле.

Это не совсем Ad hoc, т.к. есть бэклоги, приоритизация, оценки времени на выполнение задач, ограничение работы в прогрессе и т.д.
А так в целом — да, похоже на Ad hoc.

>> вверх списка поместить и получить выполненную задачу уже очень скоро.
Чем это отличается от бэклога в 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.

Я не очень-то силен в ММО, предпочитаю не трогать то, что вызывает привыкание :)
Но есть где-то в интернете рейтинги ММО по числу юзеров, денег и т.п. — можно найти.

Я смотрю в сторону .Net и Java. Они похожи на C++ и, определенно, после C++ изучить другие языки проще, чем наоборот :)

Используются для чего?
Сам код пишется на С++.
Интерфейс обычно на каком-то спец. языке для интерфейса или на 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».