• Том ДеМарко: инжиниринг ПО — идея, время которой прошло?
    –1
    Все верно вы написали, даже добавить нечего.
  • Том ДеМарко: инжиниринг ПО — идея, время которой прошло?
    –1
    >> BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении
    >> проектами» постить?

    Все равно уже на главной — все прочитают и оттуда и оттуда :)
    На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.
  • Том ДеМарко: инжиниринг ПО — идея, время которой прошло?
    0
    А попробуйте «инжиниринг» на русский перевести. «Программотехника» я нашел, но звучит по-советски. Уж лучше «индиниринг».
  • Том ДеМарко: инжиниринг ПО — идея, время которой прошло?
    0
    >> Но ни слова о том, что отсутсвие метрик — залог успеха.

    «Залога успеха» в разработке ПО вообще нет и быть не может. А уж называть «залогом успеха» отсутствие чего-то — это глупо было бы.
  • Том ДеМарко: инжиниринг ПО — идея, время которой прошло?
    +6
    Странно, может мы разные статьи читали?

    Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
    А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
  • Канбан в IT (Kanban Development)
    0
    У меня сейчас в проекте намечается момент, когда канбан может взорваться как раз из-за множества высокоприоритетных задач, которые берутся в работу немедленно. Из-за этого могут откладываться старые задачи.

    Пробую с этим справиться, но пока что таким образом, что product owner-у не отказываю, но людей со старых задач стараюсь не снимать — пытаюсь хэндлить их самостоятельно. То есть как бы есть специальный выделенный человек на «неожиданности».
  • Канбан в IT (Kanban Development)
    0
    В классическом Канбан Product Owner должен решить, какую из задач в очереди убрать и куда поместить новую высокоприоритетную. Но он не может ее впихнуть в производство, т.к. только одну может.

    У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.
  • Канбан в IT (Kanban Development)
    0
    >> Кто будет думать над hi-lvl архитектурой, когда product owner
    >> лично назначает приоритеты? Где в данной схеме место
    >> тех.лида?

    Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
    Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.
  • Канбан в IT (Kanban Development)
    0
    Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

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

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

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

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

    Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.
  • Канбан в IT (Kanban Development)
    0
    Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.

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

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

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

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

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

  • Канбан в IT (Kanban Development)
    0
    С какими, например?
    Общий случай — включать их в более крупные фичи.
  • Канбан в IT (Kanban Development)
    0
    Да, первое предложение не очень-то верно.
    Канбан — это не полноценная методология разработки. Это скорее надстройка над другими методологиями. Канбан добавляет в то, над чем он построен, некоторые плюсы, и это методология, но не полная.

    А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.
  • Канбан в IT (Kanban Development)
    0
    Канбан может быть использован вместе с Scrum или XP.
    Канбан-команда может использовать любые артефакты из других методологий, т.к. Канбан — это не методология по сути, а набор ценностей, надстройка над методологией.

    Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.
  • Канбан в IT (Kanban Development)
    0
    Приоритеты ставит product owner. И он же должен и фичам сопротивляться — он владелец проекта и он лучше всех остальных должен знать, что хорошо, а что плохо.
  • Канбан в IT (Kanban Development)
    0
    А вот еще мои слова, подтверждающие ваши: :)
    Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
  • Канбан в IT (Kanban Development)
    0
    Про приоретизацию в трех основных правилах не сказано, да. Наверное потому, что это не задача команды, а задача product owner-а, который является внешней силой.
    Про оценку времени сказано в третьем правиле.
  • Канбан в IT (Kanban Development)
    0
    Это не совсем Ad hoc, т.к. есть бэклоги, приоритизация, оценки времени на выполнение задач, ограничение работы в прогрессе и т.д.
    А так в целом — да, похоже на Ad hoc.
  • Канбан в IT (Kanban Development)
    0
    >> вверх списка поместить и получить выполненную задачу уже очень скоро.
    Чем это отличается от бэклога в scrum?


    Бэклог в скраме трогается только при планировании нового спринта и если туда что-то помещается, то в работу это пойдет только в след. спринте. А если спринт — 1 месяц, то это ой как нескоро. Да и 2 недели тоже.

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


    В целом — да. Но там по-другому нельзя — слишком много креатива, проб и ошибок.
  • Канбан в IT (Kanban Development)
    0
    Или имеется в виду, что в ваших терминах новая != непредвиденная?

    Да, новая != непредвиденная. Непредвиденные задачи — это когда у тебя распланирован спринт и все заполнено и вдруг приходит новая срочная задача. А ты сопротивляешься ей, т.к. внутри спринта задачи нельзя новые добавлять.

  • Канбан в IT (Kanban Development)
    0
    Да, конечно. В самом начале написано: новую методологию гибкой разработки Канбан
  • Канбан в IT (Kanban Development)
    0
    В Канбан нет непредвиденных задач, т.к. никто не планирует вперед. Задача обсуждается и принимается в работу только когда для нее появляется место. Поэтому если появляется новая задача — ее приоритизирует product owner и помещает в буфер задач, а оттуда она уже будет взята в разработку, когда команда доберется. А если приоритет очень высок, то можно и вверх списка поместить и получить выполненную задачу уже очень скоро.

    Имхо если 50% непредвиденных — то это уже даже не управлятор рисками дал сбой, а в понимании задачи командой что-то не то, или команда представляет из себя не то, что думает лид. И методология тут уже ИМХО влияет мало.

    В техподдержке крупной системы только так люди и работают — каждый день что-то новое :)
    В разработке компьютерных игр или других сильно «креативных» программ тоже изменений очень много постоянно.
  • Канбан в IT (Kanban Development)
    0
    Да, так и было. На спринт планнинге мы не планировали конкретные работы, а просто общались с product owner-ами и выясняли, сколько мы должны времени потратить на работу на каждого из них (т.к. у нас было несколько product owner-ов с разными целями и задачами).
    Далее каждый из них имел свой бэклог с приоритизированными задачами и мы просто брали оттуда задачи, когда заканчивали очередную и делали их. Планирования сроков никакого не было — только обсуждение технической стороны задачи, когда ее берешь.

    Опять же повторюсь — если команда работает и хочет работать хорошо, то какое еще планирование нужно? Если в бэклоге 50 задач, то мы должны все их сесть и оценить? Или мы должны, как в Scrum, оценивать только на 2 недели вперед? Так через день придет новый баг и его надо исправлять. В Scrum это решается планированием «непредвиденных задач», но если непредвиденных — 50%, то это уже глупо становится.
  • Канбан в IT (Kanban Development)
    0
    Вы похоже не поняли идею применения Канбан к IT. Конвеер — это в TPS (toyota production system), а в IT Канбан совсем о другом — о разработке новых больших фич (ММФ) как можно быстрее. Никакого конвеера нет и в помине.
  • Канбан в IT (Kanban Development)
    0
    Я работал прошлые полгода с использованием Канбан. Проект вышел достаточно успешный и все остались довольны :)

  • Канбан в IT (Kanban Development)
    +1
    Как данная методология решает основной вопросы на уровне топ-менеджмента: Когда в продакшене будет следующая стабильная версия системы?

    А как любая другая методология решает этот вопрос? Фактически никак — ставится срок на основе каких-то предварительных оценок и проект движется к этому сроку. Что успели сделать — то входит в состав проекта. Что не успели — не входит, либо срок передвигается.
    Какую методологию не используй, точно спрогнозировать вначале не сможешь. Можно только буферы задать побольше, чтобы подстраховаться.
    В Канбане тоже самое, только измерение времени идет по скорости разработки одной задачи. Если на проект есть 100 задач и мы знаем, что команда в среднем делает задачу за неделю и параллельно может делать до 5 задач, то можем считать, что через 20 недель все будет готово.

    — Методология подходит только для проектов с дедлайнами типа «when it's done» (таких меньшинство)

    Не только. Но для работы над проектами с жестким дедлайном и жестким набором фич эта методология плохо подходит — факт.

    — Оценка временнЫх факторов решения задач все равно присутствует в неявной форме в ежедневной работе менеджера

    Конечно присутствует. Иначе зачем мерять время на выполнение одной задачи?
    Менеджер (product owner) по-прежнему должен общаться с маркетингом и другими заинтересованными лицами и должен следить за конечным сроком. Инструменты для этого в Канбан есть — это время на выполнения 1 задачи и число задач, выстроенных по приоритетам.

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

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

    В моем понимании, контроль — это _управляемость_ процессом разработки, т.е. возможность направлять его в нужное на данный момент русло.

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

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

    Не согласен. Чистый Agile (Scrum) с недельными спринтами будет иметь слишком большой оверхед на поддержку методологии — слишком много «обязательных» артефактов и обсуждений. Хотя опять же все зависит от команды и условий проекта, так что тут нет общего решения.
  • Канбан в IT (Kanban Development)
    +1
    Я не говорю про TPS, я говорю про Канбан. Никто не пытается перенести всю систему работы в Тойоте в IT — это невозможно и не нужно. Да и само слово «Канбан» взято из TPS скорее потому, что красиво звучит :)

    Основа у Канбан та же, что и у TPS — уменьшение work in progress, но это и всё. Что еще взято из TPS?

    Канбан — это просто адаптация хорошей идеи к реалиям разработки ПО.
  • Канбан в IT (Kanban Development)
    +1
    >> если нет временнных отметок, как тогда продаются эти проекты?

    А как временные отметки (итерации, спринты) связаны с продажей? Итерации в Scrum или XP — это просто квант работы команды. А проект содержит результат работы нескольких команд и в течение нескольких итераций.
    В случае с Канбан никаких итераций нет — есть задачи. Они постепенно выполняются, проект наполняется фичами. В какой-то момент менеджер или product owner может решить, что проект достаточно хорош и готов к релизу и «продать» его.
    Либо же просто ждать, пока самые важные фичи не будут выполнены.
  • Канбан в IT (Kanban Development)
    +1
    Так оно обычно и получается — дял реально гибких разработчиков даже Scrum недостаточно гибок, да и не для каждой работы он подходит, так что начинают его упрощать. А тут уже и Канбан.
    Но основная идея Канбана — ограничивать число «работы в данный момент» на каждом этапе разработки. Без этого Канбан -не совсем Канбан.
  • Канбан в IT (Kanban Development)
    +3
    У нас и доски, и кофемашины, и спортзал, и чего только нет :)
    Если методология подходит команде и команда работает лучше, то она приносит больше денег фирме, а значит фирма тратит больше денег на всякие полезные мелочи.
  • ЕГЭ изнутри (глазами админа)
    +1
    Спасибо за статью. Титанический и незаметный другим труд.
  • Июньский фуршет
    0
    >> Какие из ныне существующих MMO(RP)G Вам видятся наиболее успешными? Ну, не считая World of Warcraft.

    Я не очень-то силен в ММО, предпочитаю не трогать то, что вызывает привыкание :)
    Но есть где-то в интернете рейтинги ММО по числу юзеров, денег и т.п. — можно найти.
  • Июньский фуршет
    0
    Я смотрю в сторону .Net и Java. Они похожи на C++ и, определенно, после C++ изучить другие языки проще, чем наоборот :)
  • Июньский фуршет
    0
    Используются для чего?
    Сам код пишется на С++.
    Интерфейс обычно на каком-то спец. языке для интерфейса или на Flash.
    Скрипты для миссий и т.п. — на Java, Lua, Python, C# — на чем душе угодно :)
    Некоторые даже всю логику игры на скриптовых языках пишут.

    Но вся база обычно на С++
  • Июньский фуршет
    +1
    «Тонкий» и с «хитростями» — это его и убивает. Слишком низкий уровень, слишком мало готовых компонентов по сравнению с другими языками, слишком высока вероятность ненужной ошибки и т.п.
  • Июньский фуршет
    0
    Спасибо
  • Июньский фуршет
    +1
    >> Игры на базе апи социальных сетей — ниша?

    Да, безусловно.
    У молодых команд небольших есть преимущество — на них не висят большие обязательства (по зарплате, по офису, связи с другими компаниями и т.п.), поэтому можно экспериментировать. Нужны простые интересные идеи и их можно реализовывать на всевозможных платформах:
    социальные сети, онлайн игры наподобии armorgames.com, казуальные игры. Причем из одной идеи можно сделать сразу несколько реализаций и может даже немного заработать на этом.
    А дальше — копить опыт и думать.

    >>Apple Store еще ниша?

    Ну уверен, что для начинающих это еще ниша. Слишком большая конкуренция с «большими» компаниями.
  • Июньский фуршет
    +1
    >> Принимают ли разработчики качественных коммерческих игр участие в судьбах игровых open source проектов (в
    >> свободное время или же после смены рода деятельности)?

    За всех не скажу, но кто-то принимает. У меня в команде были такие. В основном это люди, сидящие на Linux — для Linux они и пишут Open Source игры.

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

    Это не совсем так. Вся серия Quake доступна в виде исходников. Другие игры тоже можно найти. Причем вроде как из этих исходников даже можно сделать свою игру и продавать её, но я не уверен, что я правильно помню лицензию.
    Но в целом — да, не открывают код. Все считают, что имеют какие-то ноу-хау и чего-то боятся.
    Я вообще ратовал за большую открытость разработчиков, а то не только код не открывают, но даже с другими разработчиками боятся общаться, чтобы не дай бог какой секрет не рассказать.

    >> Какое направление игровой индустрии вам кажется более привлекательным (с точки зрения разработки и
    >> окупаемости) на сегодняшний день: традиционные «оффлайновые» или сугубо онлайновые игры (MMOG)? Под
    >> какие платформы: Windows, Windows+*NIX, консоли, мобильные устройства?

    Большие MMOG прибыльны при вложении очень больших средств. Без вложений — нет. Есть еще браузерки и т.п. — там не нужны почти вложения, но сейчас рынок переполнен. Офлайновые всегда были попроще в плане продаж и туда легче попасть и продать что-то хорошее. Если на консоли, то особенно выгодно.
    *nix — невыгодно совершенно.
    Мобильные устройства — нужно делать множество очень простых игр, чтобы что-то заработать. 1-ой игрой не заработаешь.

    В общем, бизнес очень интересный и сложный — несколько крупнейших компаний имеют 80% прибыли, а все остальные сидят на оставшихся 20%. Чтобы зарабатывать миллионы нужно делать очень качественный продукт, то есть тратить миллионы. А не имея миллионов расчитывать на большие заработки почти невозможно.
    Но бывают исключения — например, серия «Космических рейнджеров» и теперь «Kings Bounty».
  • Июньский фуршет
    0
    В роли пользователя.
  • Июньский фуршет
    0
    >> Могу даже ссылку дать: habrahabr.ru/blogs/python/47474/

    Понятно. Python для администрирования, интересная идея :)
    У нас Python в основном для тестирования и тулзов используется — тест кейзы, система автотестирования, системы сборки и т.п.