Разработка игр в Post-Agile мире

21 комментарий
Разработка игр в Post-Agile мире
Post agile Фанатичная уверенность в своей правоте и агрессивный рекламный напор Agile-евангелистов оставили после себя поля заваленных проектов, руины бизнес-начинаний и заблудших неофитов, всё ещё блеющих избитые истины забытых пророков. Индустрия разработки игр не исключение в данном случае и также ещё только начинает осознавать масштаб фантасмагории и её результаты. Конечно, всегда были более осознанные разработчики, которые не поддались уговорам и влиянию никуда негодных "консультантов", даже если они предлагали громкие сертификаты и все прочее. Сейчас среди прогрессивных специалистов часто говорят о так называемых post-agile практиках, ранее известных как здравый смысл. Но распространяется этот самый здравый смысл пока ещё медленно. Если мне придётся ещё раз просидеть на митинге с каким-нибудь очередным agile неудачником, упорно защищающим свой подход к разработке катящегося в бездну проекта, это всё приведёт к принудительному канбану (японская система синхронизации работы на заводах с раздачей карточек с требованиями), где никаким scrum'ом и не пахнет. И не то чтобы я имел что-то против agile, скорее совсем наоборот, но в конце дня мне надо сделать поставку, а не бороться с ветряными мельницами. Опыт управления проектами в индустрии, которая только выходит из подросткового возраста, набирается методом проб и ошибок. Прежде чем делать какие-то выводы о современном состоянии дел в гейм-индустрии, стоит сделать шаг назад и рассмотреть подробнее саму agile методику, разобраться, что она из себя представляет. Я работаю техническим директором большой студии, и поэтому под моим контролем находятся все проекты компании. Кроме того мне приходится и вплотную общаться и тесно взаимодействовать с издателями и коллегами по отрасли. Неудивительно, что у меня по долгу службы хватает возможностей увидеть всевозможные стили управления разработкой, так сказать, ”в живую”. Agile стал одним основным трендом в последние годы, но кроме него самого стоит уделить внимание другим, сопутствующим данной методике трендам. В первую очередь многие уверены, что слова agile и scrum взаимозаменяемы, и мысль о том, что это два независимых понятия кажется им совершенно чужеродной и инопланетной. Несмотря на распространённость scrum'а, ощущается недостаток чёткого понимания scrum-отношений во многих командах. Если проследить, что собственно делают команды день за днём, можно заметить, что "scrum" на удивление разнообразен и вариативен. Иногда, даже сложно найти связь между тем, что команды делают и тем, что в моём понимании они должны были бы делать. Другим распространённым мнением является то, что альтернативой agile является waterfall. Многие действительно так думают. В результате, если ты не приверженец agile, то ты — ретроград, застрявший в прошлом, и отчаянно за это самое прошлое цепляющийся. Тебе нужно прозреть, просветлиться, или, что ещё хуже, как оказывается, ты просто не способен понять, как на самом деле надо действовать. Мы все с вами, наверное, в какой-то момент испытали на себе все прелести плохого менеджмента и поэтому прекрасно пониманием тоску девелоперов в таких случаях, и их стенания по поводу организации более человеческого и вменяемого рабочего процесса, а agile как раз выглядит такой симпатичной альтернативой традиционным правилам и распорядку. В то же самое время менеджмент самого себя постоянно жалеет, сетуя на то, какие же всё-таки наивные девелоперы, и как они мало понимают реальности ведения бизнеса. Существует общее недопонимание того, что из себя в действительности представляет agile, какие вопросы данная методика ставит перед командой и как вписывается в общую картину создания какого-либо решения. К сожалению, подобное неведение, а иногда и даже невежество, не позволяет многим вести конструктивный диалог и мне зачастую приходится тратить довольно много времени, чтобы сломать, наконец, бесполезные философские барьеры в сознании собеседника, прежде чем перейти к обсуждению актуальных проблем. А это, откровенно говоря, весьма раздражает, ведь всё самое важное часто остаётся не раскрытым за всеми этими разглагольствованиями. Многие думают, что agile это какая-то исключительно новая практика и посвящена решению каких-то совсем свежих вопросов, буквально только сейчас ставших актуальными. Вообще-то, менеджмент проектов насчитывает в своей истории сотни лет, да и в сфере разработке ПО его история идёт не один десяток лет. Если брать за основу идеи о реализации как можно более эффективного производства, то тогда agile мышление существует как минимум с 40-ых годов прошлого века. В любом случае, agile родился в результате обобщения большого количества знаний, эмпирических данных и практического опыта, на основе которых, и были сделаны некоторые осмысленные заключения и придуманы правила. Если же возвращаться обратно к разработке ПО, то если приглядеться, то можно заметить, что существует не так уж и мало формализованных методик ведения разработки, а не только Scrum или Waterfall. Вот несколько, навскидку: Некоторые из них считаются преимущественно agile методиками, некоторые нет. Все из них имеют своих приверженцев, и на каждой из них было успешно реализовано множество проектов, что вызывает естественно возникающие вопросы: Если они все успешны, то почему так важно, какую из них в конкретном случае надо использовать? Может некоторые из них более эффективны, чем другие? Тогда почему и чем? Если есть больше чем один подход к agile, то почему именно scrum так популярен? Он действительно лучший в своём классе или у него просто более звучный пиар? Разумеется, мы не первые, кто задаётся подобными вопросами в попытках оценить эффективность различных техник менеджмента проекта. Например, американское министерство обороны, разработало Capability Maturity Model (CMM) специально для оценки способностей разработки и управления проектами у потенциальных военных подрядчиков.

Но, так или иначе, начнём с менее глобального вопроса.

Из перечисленных выше методологий, какие более соответствуют принципам agile, а какие менее? More less agile Простой вопрос, но для ответа для него нам нужно напомнить формальное значение термина "agile". К счастью разногласий здесь быть особо не должно, поскольку Agile Манифест приводит нам достаточно ясную формулировку. Вообще мне нравится манифест, поскольку он показывает ясное понимание что такое, процесс разработки ПО и предлагает хорошо продуманную систему ценностей. Он содержит важные идеи, которые никто не должен пропустить. Рассмотрим первый принцип: Люди и их взаимодействие важнее, чем процессы и средства. Смелое заявление от авторов манифеста (не зря оно и первым идёт), ставящее личное взаимодействие выше процессо-ориентированных аспектов разработки. Оно даёт нам более чёткий способ ранжирования методик по соответствию их agile принципам. Техники, сфокусированные на самих разработчиках более agile, чем процессо-ориентированные. Конечно, это только один пункт для сравнения и подобная классификация методик будет слишком грубой и сырой, но взять её на заметку стоит.  техники, сфокусированные на самих разработчиках более agile, чем процессо-ориентированные. Уточним, что подразумевается под терминами "человеко-ориентированный" и "процессо-ориентированный". Идея процесса имеет явно "политический" подтекст и поэтому люди так эмоционально реагируют, когда слышат о "методологиях" управления проектом. Ведёт данная идея к более фундаментальным и при этом более общим концепциям. Процесс — это инструмент власти. Процесс — это утверждение о том, что как и в каком порядке надо делать. Процесс консервативен, иерархичен и формализован. Процесс устанавливает статус-кво в игре. С его помощью менеджмент наводит порядок сверху вниз. Если бы процесс был политической партией, он бы принадлежал к правому гегелевскому лагерю. Альтернативой процессу является делегирование ответственности, доверие лицам на местах должным образом организовать себя, поскольку они лучше знают конкретные задачи, и поэтому так будет эффективнее, а сама разработка соответственно продуктивнее. Самоорганизация либеральна, "коммунальна", неформальна и даёт шанс каждому проявить свои способности. Она зарождается и идёт снизу вверх. Если продолжать политические метафоры, то самоорганизация — это партия хиппи в одежде из конопли и левацкими убеждениями. Если говорить более конкретно и попытаться материализовать столь общие слова, будем считать процесс принадлежностью и чертой традиционного типа разработки ПО, а самоорганизацию своеобразной софтварной вольницей-партизанщиной. М-да, не особо получилось материализовать, поэтому совсем неудивительно, что вокруг данного дискурса постоянно ведутся эмоциональные дискуссии. Подобная условность и неопределённость — плодородная почва для агитации и слепой веры в свою правоту. Не спрашивали себя, почему существует именно манифест agile? Это по сути как раз какое-то воззвание, можно сказать политическая позиция, а не какая-то объективная позиция. Я не партизан, но и к другому лагерю также не принадлежу. Я просто заинтересован в получении конечного результата, и у меня нет времени защищать какую-то конкретную точку зрения. А для эффективного получения результата и вовремя необходимо быть гибким (хотя и не всегда, я бы добавил), так что главное понимать правильно, чего полезного можно получить от обоих подходов.

Итак, что же хорошего в процессах?

  • Повторяющиеся и предсказуемые результаты
  • Гарантии качества (за счёт предсказуемости)
  • Экономия средств за счет возможности оптимизировать рабочие процессы
  • Определённый конкретизированный поток работ позволяет нам использовать дешевый труд
  • Возможность распространения передового опыта и сохранение концептуальной целостности проекта
  • Возможность масштабирования
  • Возможность эффективного отслеживания прогресса согласно поставленным целям
McDonalds является прекрасным примером успешного процесса. Неважно, где вы находитесь в мире, вы знаете, что вы получите, и что вы получите это быстро и дешево. Этот процесс успешно масштабируется до тысяч ресторанов. В независимости от того нравится вам фастфуд или нет, но с результатами спорить трудно. Тем не менее, разработка программного обеспечения намного сложнее, чем жарка бургеров. Процесс в случае ПО может быть неподходящим или неконструктивным.

Процесс может:

  • Увеличить расходы и снизить производительность через бюрократические издержки и потерю времени
  • Мешать нашей способности изменятся и адаптироваться к новой ситуации
  • Задушить нашу тягу к новаторству и творчеству
  • Требуют дисциплины и подготовки
  • Эффективно применим только для известных величин
Вполне логично, что данные утверждения обратны для человеко-ориентированного подхода. Если доводить до крайностей, то в случае процесса проект начнёт задыхаться от бюрократической волокиты, заполнения бесконечных отчётов и форм (как это бывает, когда чем-то занимается государство). В обратном случае — при отсутствии процесса в принципе, проект превратится в хаотический беспорядок нескоординированных действий, приводящих к потере энергии впустую и крохами на выходе (э, ну да, это как когда чем-то занимается государство). Разумеется, это всё крайности и никогда не бывает так в реальности, что был только жёсткий процесс или только анархичная вольница. Хитрость состоит в том, что надо уметь определять когда нам необходим чёткий процесс, а на каком этапе можно расслабить обстановку и снизить строгость требований. Хороший менеджмент — это, прежде всего гибкость расстановки приоритетов и понимания, когда применять тот или иной подход. Множество проектов было завалено только по тому, что на них пытались применить целиком и не меняя набор действий и техник, которые себя успешно зарекомендовали в предыдущий раз, не понимая толком того, что в действительности привело предыдущий проект к успеху. Все проекты имеют свои важные моменты, различные критерии, которым необходимо соответствовать и удовлетворять, чтобы соблюдать баланс. Когда я сажусь в 747-й для трансатлантического перелёта, для меня всё-таки действительно важно долететь до места назначения, а не грохнуться где-нибудь посреди океана, поскольку какой-то клоун точку с запятой не поставил. Это несколько проблематично перезапустить самолёт после крушения, чтобы посмотреть "не будет ли он ещё падать". Критически важные с точки зрения безопасности системы требуют гарантий того, что они будут корректно работать в рамках чётко прописанных параметров и условий. Безопасность в данном случае куда важнее стоимости и скорости разработки, и именно процесс нам может дать необходимые гарантии. С другой стороны обновлять e-commerce сайт информацией и материалами о новых скидках или ещё чего-нибудь требует реагировать быстро, и здесь вольница agile даёт нам возможность сделать это быстр и избежав рутины. Не будем ударяться в крайности — даже для очень похожих проектов цели могут быть разными. В гейм-девелопменте, к примеру, сохранить бюджет под контролем и при этом успеть попасть на полки к Рождеству может быть критически важным для проекта. Поскольку создание нового бренда может быть важнее качества. Давайте закончим с представлением и рассуждениями, время расставить наши методы, согласно тому, насколько они процессо или человеко-ориентированы. Методы разработки по Вы, наверное, хотите спросить, почему я решил, что какой-то конкретный метод более или менее процессо-ориентирован, чем другой. Всё субъективно, и вы вполне можете не согласиться с моей позицией, и вполне возможно будете правы. Проблема в том, что каждый конкретный метод содержит микс из различных (и вполне вероятно пересекающихся) практик. Кроме того уровень строгости и степень формализованности процесса могут меняться в зависимости от конкретного случая использования

Рассмотрим Scrum. Прежде всего, Scrum это:

  • Спринты
  • Scrum роли
  • Митинг по планированию спринта (sprint planning meeting)
  • Ретроспектива спринта
  • Демонстрационный митинг (Sprint Review Meeting)
  • Истории (user stories)
  • Ежедневный митинг (Daily scrums)
  • Предварительный cписок запросов на выполнение работ (Estimated Backlog)
  • Burn Down Charts
  • Планирование релиза (Release Planning)
  • Стэйкхолдеры (Stakeholders Collaboration)
  • Кроме того в понятие Scrum включают такие практики как:
  • Task Boards (канбан)
  • Test Driven Design (TDD)
Очевидно, что некоторые из этих понятий скорее человеко-ориентированные, например daily scrums, а вот TDD и Burn Down Charts, на мой взгляд, скорее относятся к характеристикам процессного подхода. Майкрософт опубликовал данные, полученные эмпирическим путём, о том, что TDD техника разработки увеличивает размер затрачиваемых усилий на 15-35%. Несмотря на все выгоды от применения TDD, мы не можем себе позволять себе тратить дополнительно 35 процентов времени на артефакты, которые заказчик никогда не увидит. Удивительно, но при этом люди всё ещё пытаются связать данную технику с agile разработкой. Чтобы получить более точную картину, мы должны рассматривать каждую методологию, как динамичный диапазон действий, охватывающий все мероприятия, которое выполняются в соответствии с фактической реальной практикой. Scrum Я хотел бы подчеркнуть, что когда мы переходим к деталям, определяя, что agile, а что не agile, нельзя прямо и чётко сказать, что это надо использовать, а это не надо. Agile является необходимым и важным контрапунктом традиционного мышления разработки программного обеспечения, но при этом является лишь малой частью общей картины. Я видел очень успешные agile команды, но и много других, которые терпели неудачу за неудачей. Точно также есть команды, которые успешно работают по процессной методике, а есть постоянно неуспевающие к дедлайну. Очевидно, что успешность проекта далеко не определяется каким-то конкретным подходом к управлению разработкой, и проблема куда сложнее, чем мы могли подумать сначала. Есть много вещей, которые вносят вклад в будущий успех проекта и не все они определяются только нами. Хотя и гарантий давать нельзя, но, всё же, если мы тщательно разложим всё по полочкам до деталей, шансов на успех у нас будет больше. Возможно слова о том, что надо для начала подобрать наиболее подходящие техники-инструменты разработки, не несут в себе какой-то новой истины и глубины. Но, так или иначе, мне кажется, что некоторым людям действительно надо это лишний раз услышать, и эти самые слова важны. Когда мы пришли к выводу о том, что agile это всего лишь один инструмент из многих, всё стало только интереснее. Как я узнаю, какой инструмент будет наиболее эффективным для решения данной задачи? Какой выбор инструментов у меня собственно есть? Какие базовые и основные характеристики различных задач? Человек и процесс — это удобная конструкция для иллюстрации идеи, но она только открывает игру. Чтобы ответить на все эти вопросы мы должны спуститься в самый низ и рассмотреть все мелкие подробности и особенности, стоящей перед нами задачи. Каждая игра, каждая команда, каждая компания — уникальна, и существует много факторов способных повлиять на ход разработки — размер команды, корпоративная культура, внутренняя политика, лимит на бюджет, физические ограничения и так далее. Есть, конечно, какие-то общие моменты среди всех эти уникальных проектов. Есть много книг, которые рассказывают о каких-то базовых принципах, поэтому я лучше выберу те пять моментов, которые мне кажутся важными и определяющими в гейм-девелопменте.

Люди.



Я уверен, что важнейшим фактором успеха в управлении проектом являются люди. Талантливые мотивированные опытные разработчики сделают поставку, несмотря на огрехи менеджмента. Они найдут способ обойти процессы, которые мешают и смогут создать правильную структуру там, где царит хаос.
"Окружите себя лучшими людьми, которых только сможете найти, распределите обязанности и полномочия, и не вмешивайтесь", Рональд Рейган
Эта идея лежит в основе agile девелопмента, и является фундаментальной для нелинейного менеджмента. Чтобы добиться успеха, вы должны приложить максимум усилий, чтобы нанять хороших разработчиков, тщательно отсеять зёрна от плевел. Весь остальной менеджмент в таком случае особой роли не играет, это так, глазурь на торт. Разумеется, рассчитывать на то, что вы набираете всегда только лучших, наивно. Вот несколько факторов, которые надо учитывать:
  • Если вам потребуется существенно увеличить команду, то будьте уверены, что проблемы с наймом ещё одних лучших у вас возникнут.
  • Опыт — штука дорогая, ваш бюджет вряд ли потянет команду исключительно элитных разработчиков.
  • Определение зон ответственности. Понимание того, где мы можем нанять не сильно опытного человека, помогает перекинуть бюджет на другую зону или же просто сэкономить и тем самым увеличить коммерческую состоятельность вашего проекта. (Вы не будут набирать в Макдональдс исключительно кандидатов наук на все должности, хотя попробовать было бы интересно).
  • Слишком много ведущих разработчиков — путь к появлению проблем. Кто будет главным, и станут ли опытные разработчики играть вторые скрипки? Неясное распределение полномочий ведёт к разрушению концептуальной целостности проекта.
В то же самое время, тот факт, что вам приходится часто работать банально с тем, что есть, приводит к тому, что понимание способностей и склонностей человека, и то, как они реагируют на те или иные ситуации, становится ключевым качеством хорошего менеджера. Некоторым больше по душе свобода, а кому-то нравится больше работать в чёткой структурированном окружении, к примеру. Большинство agile методик предполагает, что у вас под началом великолепная, опытная и сверхмотивированная команда. Многие такие методики могут и вполне хорошо работать с командой обычных, юных или апатичных разработчиков, а могут и с оглушительным треском провалиться. Опыт в данном случае имеет большое значение. К примеру, я могу взять своего лучшего девелопера, поставить перед ним какую-то сложную техническую задачу, дать всё, что ему требуется, и сесть на стул, сложив руки в ожидании чуда. А вот если всё то же самое проделать перед только пришедшим из университета свежеиспечённым разработчиком чуда можно даже и не начинать ждать. Большинству начинающих нужно наставничество, постоянный контроль и чёткие структурированные задачи, пока он сам не встанет на ноги. Из этого следует, что процессо-ориентированный подход больше подходит для джуниоров, а для опытных разработчиков лучше как раз человеко-ориентированный. соответственно мы видим, что компоновка команды по принципу уровня опытности определяет и подход, который должен лучше сработать. Конечно, люди куда более сложны и идиосинкратичны, чтобы было достаточно выбора методики по опытности девелоперов. Но главное, что я хотел сказать, это просто то, что разные люди откликаются на разные подходы, и что опыт и скиллы команды обязательно надо принимать во внимание, прежде чем выбирать подход к разработке — плановый или agile.

Креативность vs. Продакшн

Есть два фундаментальных понятия, лежащие в основе гейм девелопмента — креативность и продакшн (прим. – перевод слова "продакшн", как "производство" или "производственный процесс", будет вносить сумятицу, поэтому оставлю такой, более понятный людям в теме вариант) Давление продакшна на разработку это обычное условие ведения бизнеса — необходимость совершить поставку согласно бюджету ни в срок. Чтобы сделать это, нам необходимо просчитать масштаб работ и риски, а это значит заняться планированием и составлением графиков работ. Это несомненно сложная работа, требующая немало усилий и времени, но необходимая для того чтобы ответить на эти извечные два вопроса — когда это будет готово и сколько это будет стоить? Чтобы план был точным и аккуратным, в идеале нам надо работать с известными величинами. Продакшн, таким образом, отправляет нас в сторону техник, работающих от процесса. Креативность, с другой стороны, это сердце и душа гейм девелопмента, которая заставляет нас делать лучшие игры. Это увлекательный путь познания и искреннего любопытства. Здесь нет гарантированного выхода или удобных сроков, и это разочаровывающий путь, с точки зрения перспективы выпуска продукта. Наличие креативности у разработчиков часто приводит к попыткам менеджмента управлять всем этим хаосом, которые, впрочем, не могут сдержать творческий процесс, а менеджеры потом только удивляются уменьшению количества "я не знаю что это" ошибок. Поэтому не удивительно, что некоторые наиболее инновационные и продвинутые игры, получившие высокую оценку от самых взыскательных критиков, выходят из студий, чей менеджмент можно, прости господи, назвать беспорядочным. Точно также "корпоративные" студии со зрелым и опытным менеджментом, выпускают банальные и стандартные продукты. Но не стоит торопиться с выводами. Это всё не значит, что креативность это прерогатива хаоса, а своевременная поставка игры и попадание в бюджет означает отказ от инноваций. Нам необходим баланс между обеими крайностями, чтобы достичь желанной цели. Понятие креативность окружено мистически ореолом, особенно в том, что касается компьютерных игр. Это на самом деле важная и большая тема, но она выходит за пределы этого эссе. Тем не менее, люди изучают так называемую креативность годами, и существуют наработанные эффективные практики и техники, пригодные к использованию. Креативность — это навык, которому можно научиться, воспитать и развить в себе. Это куда меньше чем какой-то проблеск гениальности, это скорее умение создать вокруг себя условия, стимулирующие появление и развитие идей. Если вам это интересно, советую прочитать книгу Гордона Маккензи (Gordon Mackenzie) "Orbiting the Giant Hairball", которая рассказывает о его опыте креативной работы в корпоративной среде. Повторяющаяся и при этом постоянно изменчивая натура креативного процесса ведёт к самопроизвольному принятию agile-ориентированного стиля менеджмента. Тем не менее, наивно применять scrum в надежде, что это магически сделает разработку более креативной. Гибкость менеджмента необходима, но не определяет итог разработки. Сочетать в гармонии креативность и продакшн нелегко, тем более что далеко не все проекты в данном плане похожи. Как бы мне не хотелось работать всегда над инновационными и креативными задачами, такого никогда не будет. В реальной жизни бизнес показатели и характеристики, в том числе пресловутый продакшн, являются наиважнейшими для большинства компаний. Устойчивый и успешный бизнес должен быть всегда прибыльным. Если мы хотим всегда обеспечивать сотрудников студии работой и продолжать разрабатывать игры, мы должны быть прибыльным бизнесом. Для примера, пропуск платежа за очередной майлстоун проекта может быть фатальным для стартапа, живущего "от получки до получки", так что своевременная поставка (синоним — выживание) в данном случае куда важнее всего остального для проекта. Или, к примеру, крупный издатель может захотеть получить не просто игру, а новый бренд, который воздастся им в будущем большей прибылью. И для проекта у них будет куда больше желания подождать и вложить больше денег в креатив разработчиков и в них самих. Портфолио продуктов — ещё одна вещь, которую необходимо учитывать — большая студия может работать над одним проектом "для оплаты расходов" (то есть бизнес-ориентированный, в котором важнее всего своевременная поставка), а вторым заниматься для поддержания престижа студии (креативным и инновационным). Понимание контекста бизнес-реалий для данной игры, её возможностей и амбиций, определяет лучший путь для её разработки и развития. Некоторые люди склонны считать, что коммерческий успех, так или иначе, последует за выпуском хорошей игры. Это конечно вполне возможно, а для идеального мира "где всем воздаётся по заслугам" будет истинно верным. Но, так или иначе, мы живём в несколько ином мире, который совсем не так прост. Это правда, что некоторые студии нашли себе нишу и открыли новые сегменты рынка за счёт своей креативности и продвинутости, и это привело их к коммерческому успеху и интересу инвесторов. Но, к сожалению, это работает не для всех, и проблему у многих начинают возникать, когда им оказывается необходимым оставаться креативными и инновационными на протяжении долгого срока, а не одного-двух проектов. Вообще, я желаю всем им удачи, однако только рынок станет всем судьёй.

Этапы продакшна

Ещё один момент, свойственный индустрии разработки игр (а также любому фактически конечному продукту), это разбивка проекта на три этапа — преподакшн, продакшн и постпродакшн. Точные определения данных вех в разработке могут меняться в зависимости от проекта, но в общем виде я их представлю так:
  • Препродакшн — это период, в который мы работаем над тем, какой должна быть игра, и как мы собираемся её делать
  • Продакшн — период, в который, мы собственно, делаем игру.
  • Постпродакшн — период, в который мы заканчиваем разработку и превращаем проект в нормальный, готовый к доставке пользователю продукт. Данный этап делится на две фазы — альфа (полировка игровых моментов, отработка баланса игровых качеств и процесса) и бета (чистка от багов).
Забавно, но даже самый ярый приверженец agile методик, которого я когда-либо встречал, всё равно ссылается на существование данных этапов разработки, несмотря на то, что они практически полностью повторяют стадии waterfall подхода — дизайн, реализация, тестирование. Так уж получилось, что данная разбивка на этапы является фундаментальной для индустрии. Agile методики предпочитают итерации разработке согласно структурированному плану. Такой подход работает, когда условия и требования постоянно меняются и перестройка плана каждый раз отнимает слишком много усилий и времени. В гейм-девелопменте требования меняются постоянно, и в данном случае вполне логично, что итерационный подход является естественным. Мы можем применить данный подход к проекту в целом, заменив тем самые стандартные пре, продакшн и постпродакшн этапы и получим что-то вроде этого: Итеративный цикл 
 Так или иначе, проблема заключается в росте количества изменений, которые необходимо производить на высоких стадиях развития проекта. Скажем, мы решили изменить длину прыжка героя, достаточно невинное изменение, влекущее, однако за собой серьёзную переделку дизайна уровней и потенциально ещё энного количества систем и контента. Чем больше уровней мы сделали, тем дороже нам обходятся изменения. Цена изменений в зависимости от этапа разработки Выше представлен график традиционной стоимости изменений, который вы можете найти во многих книгах, посвящённых разработке софта. Чем раньше мы делаем изменения, тем дешевле они нам обходятся. Применяя итеративный подход к полному циклу разработки, мы потенциально наращиваем стоимость последующих изменений. В идеале, нам бы хотелось ответить на все фундаментальные вопросы в самом начале разработки, чтоб потом не пришлось вносить дорогостоящие изменения. И препродакшн как раз нацелен именно на это. Препродакшн — наиболее креативный период создания любой игры. Начальные этапы препродакшна на редкость свободны и органичны, в них есть элемент творчества и изобретательства. Более поздние стадии данного периода разработки сфокусированы на решение специфических вопросов и выбора технологий, чтобы последующая разработка была эффективной и правильно размеренной. В целом, если и есть когда период времени, когда вы эффективно работаете по agile и ведете процесс разработки по итерациям — это будет называться препродакшеном. Продакшн — это период, когда мы создаём основной контент, и в который мы тратим больше всего денег. Нам необходимо удержать расходы под контролем, и чем лучше процесс организован и детерминирован, тем лучше. Мы всё ещё должны реагировать на фидбэк и вносить изменения, однако мы должны держать всё это под контролем. В альфе мы возвращаемся обратно в итерационный цикл — уточняем, полируем, настраиваем. После альфы, каждый работает уже из базы багов, процесс, на мой взгляд, органичный и самоподдерживающийся. Мы можем изменять подход к разработке на протяжении всего жизненного цикла проекта, мы не должны всегда придерживаться одних и тех же принципов.

Навыки



Другим отличным моментом игровой индустрии по сравнению с другими средами разработки являются необходимые навыки — в гейм-девелопменте сплетаются три фундаментальные стихии: кодинг, искусство и дизайн. Различные виды задач и их реализация, сложная система взаимопроникновения и взаимодействия дисциплин — тема которую нельзя не оставить без внимания. Анализируя метрики с наших внутренних проектов, я выделил несколько общих трендов: Искусство претендует на то чтобы называться детерминированной дисциплиной. Как только мы сгенерировали список необходимых элементов и объектов, а также соответствующий антураж, мы можем с большой долей вероятности предсказать, как много времени займёт реализация всего этого, и какого качества результат мы сможем получить. Кроме того данный тип работ легко распределять на несколько людей и можно без проблем для ускорения работ внедрят в команду новых специалистов. Кодирование куда более эклектично и имеет массу непредсказуемых моментов, влияющих на процесс разработки. Для сравнения — данные исследований показывают, что программисты тратят существенную часть времени в работе (20-40 процентов) на незапланированные задачи. Это происходит потому, что им приходится реагировать на возникающие в процессе разработки запросы куда чаще, им приходится работать над багами или сражаться со скрытыми сложностями и огрехами дизайна функционала. Кроме того сложные системы куда хуже распределяются и масштабируются, и поэтому введение новых людей в коллектив не всегда приводит к улучшению результата и ускорению работ. Из этого следует то, что одни и те же методы управления, успешно применённые к художникам и дизайнерам, далеко не всегда подойдет программистам и стоит дифференцировать ваш подход к менеджменту в зависимости от подчинённых и выполняемых ими задач. К примеру, вы можете вести кодеров по agile принципам, а к работникам визуального искусства применять более плановый подход, особенно во время продакшена.

Клиент

Ещё один интересный момент в agile разработке — это желательное вовлечение в процесс заказчика. В нашем случае для простоты возьмём в качестве заказчика представителей компании, выпускающей игры в печать. В гейм-девелопменте у нас всегда наблюдается участие заказчика в процессе разработки в виде внешнего продюсера игры, который играет роль телеграфа, передаёт слова заинтересованных сторон со стороны паблишера (маркетологов, юристов, QA и т.д.). Это выглядит правильно и даже благородно вовлекать в сотрудничество заказчика в процессе разработки, однако далеко не все заказчики и их представители одинаковы. Есть множество сложных вопросов и принципиальных моментов в данном сотрудничестве — сколько доверия и свободы в решения они готовы вам предоставить? Какого уровня вмешательства в процесс разработки вам стоит ожидать? Какой вес представитель заказчика имеет в его бизнесе? Приведём совет, который может поспособствовать созданию на проекте тех условий, которые помогут и проекту выжить, и понять, как внешние силы могут вам помочь в планировании стратегии реализации проекта, а также стиля применяемого на проекте менеджмента. Говоря утрированно, если у вас клиент-живчик, постоянно меняющий и добавляющий цели и задачи, то ваш лучший друг — agile. Если же вам попался клиент, который не сильно увлечён непосредственно качествами результата разработки, а требует, чтобы всё было сделано в срок и в бюджет, то тогда вам поможет только хорошее планирование и размеренная работа. Спор насчёт agile и waterfall на самом деле прост. Моё мнение — agile не плох, просто он слишком часто используется в качестве оправдания для плохого менеджмента на проекте. Разработка софта — сложная штука, а разработка игр в особенности. Достаточно только бросить взгляд на поле разработки ПО, чтобы увидеть там ряды могилок загубленных проектов, чтобы подтвердить данное утверждение. С другой стороны, если бы разработка ПО была простой, она бы не была такой интересной. Пока мы закрываем глаза на принципиальные фундаментальные вопросы, у различного рода шарлатанов есть непаханое поле для активной деятельности по продажам живой воды для проектов и философского камня для управления разработкой. Оглядывайтесь назад, чтобы пересматривать свои собственные убеждения, вырабатывайте свою собственную позицию. При этом чтобы успешно развивать свои навыки управления проектами, не бойтесь пробовать новые методики, экспериментируйте. Но самое главное, не забывайте, что от своей работы вы должны получать удовольствие. В конце концов, ведь именно поэтому мы занимаемся разработкой игр. И помните, не бывает двух одинаковых проектов (если вы, конечно, не занимаетесь разработкой гоночных симуляторов :).

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

Стартап, созданный белорусами, стал продуктом месяца на Product Hunt
Стартап, созданный белорусами, стал продуктом месяца на Product Hunt

Стартап, созданный белорусами, стал продуктом месяца на Product Hunt

Notion снял ограничения в бесплатном тарифе
Notion снял ограничения в бесплатном тарифе

Notion снял ограничения в бесплатном тарифе

2 комментария
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19
Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

2 комментария

Обсуждение

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
-1

В принципе правильные мысли. Хотя немного сумбурно и есть неточности (Prince2 - не методика ведения разработки, PMP перепутан с PMBOK и тоже не методика ведения разработки, расстановка методик на шкале People<>Process очень загадочна и т.д.). Более системный взгляд - вот здесь: http://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125 .

-1

Достаточно противоречивая статья. Непонятно, причем здесь game development, где хоть одно отличие от обычного проекта?
Понравилась фраза "Если же вам попался клиент, который не сильно увлечён непосредственно качествами результата разработки, а требует, чтобы всё было сделано в срок и в бюджет". По народному - если заказчик лох - разводи по полной, так что ли? Или здесь перевод неверный? Заказчик - просто мечта оутсорсера.

Про TDD. Для меня TDD
1. Простейший и наибыстрейший способ постановки задачи для малоопытных коллег - Сделай так, чтобы тест прошел. - тут не затраты времени, а экономия, и при формулировке, и при проверке выполнения.
2. Возможность спокойно спать после глобальных переделок - прошли тесты значит в старом ничего не сломал. На текущем проекте уже раз 20 падал билд при прогонке тестов, когда изменения в одном конце проекта, как оказалось, повлияли на совсем другом. Если у вас не так, значит или проект у вас небольшой, или вы БОГ.
И 1 и 2 больше к людям, чем к процессам.
И опять статья западная, предполагает что ПМ все знает и умеет. У нас зачастую ПМы имеют минимальный опыт программирования, если имеют вообще. Человека, занимавшегося WinForm могут поставить руководить проектом на Web services и наоборот. Он там такого наwaterfallит. В agile трудооценка, пусть и локальная, ложится на команду, а они должны знать, что делать, или здравствуй, овертайминг.

В защиту Макдональдс. Фраза "Тем не менее, разработка программного обеспечения намного сложнее, чем жарка бургеров." подмывает спросить, а сколько бургеров испек автор? Мое вчерашнее 8-ми мартовское участие в приготовлении яблочного штруделя переплюнет недельный code development.

При сравнении подходов в разработке, с моей точки зрения, больше бы подошло сравнение с embedded software development или АСУ ТП, например, там требование к качеству иное и процессы соответственно другие. Одно дело форма зависла на обычном desktop приложении, и совсем другое, когда болванка в полторы тонны стену пробивает. Выложил update на сервер или пару миллионов машин отозвал...

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
0

Не согласен по ряду пунктов.

1. Есть проекты, для которых срок и/или бюджет важнее качества. Лохи здесь не при чём. Хрестоматийный пример - подготовка сооружений к Олимпиаде: не успеете в срок - ваше суперкачество никому не понадобится. Кстати в embedded SW такое - сплошь и рядом.

2. TDD очень классная штука, если не думать о затратах на поддержание тестов в консистентном состоянии - особенно в условиях интенсивно меняющихся требований. Интуитивно представляется естественным писать тесты по достижении определённого уровня стабильности требований - иногда это может быть до первых итераций кодирования, иногда - одновременно или после (особенно когда используем development by prototyping).

3. Насчёт оценки трудозатрат. Нет противоречия между оценкой PM-ом и оценкой командой - PM и команда работают вместе. Если оценка осуществляется снизу вверх - задачи имплементации оценивают технические эксперты (в идеале - потенциальные исполнители), PM накладывает коэффициенты для учёта рисков и ещё много чего (интеграция, управление требованиями и т.д.). Каждый компетентен в своей области. То, что вы называете трудооценкой в agile (на самом деле в Scrum, что не одно и то же), - это краткосрочная оценка: на спринт или чуть дольше. На одних краткосрочных вы далеко не уедете.

-1

Все можно обсуждать:)
1. Построили в срок, но на открытии трибуна упала.
2. В TDD тесты до разработки или вместе с ней, а не по достижению какого-то уровня. Если Вы не знаете, что хотите получить в итоге - что собираетесь писать?
3. Дело в психологии, ни один ПМ не заставит меня лично пойти на овертайм, если лопухнулся в сроках он. Ошибся я - сам виноват. Все зависит от человека. Знаю примеры когда люди годами!!! работают без выходных и по ночам из-за ошибок проектирования - это просто не ко мне.

Про embeddded, автор сам не зря отписал про Боинг, он ведь не игрушечный имел ввиду. Там свои особенности, Вы не можете сдать бортовой компьютер автомобиля, пока не сделают датчики закрывания дверей или уровнемер в бензобаке. И наоборот, датчик не поверят и не сдадут, пока Вы его не опросите и проверите - привязка к общему производству и как следствие карточная система и waterfall.
Делали ADSL2 модем, прошивка - только начало, дальше тестирование с 20 DSLAM на совместимость, с 10 OS на совместимость драйверов и 10 браузерами на совместимость web интерфейса. А бывает, что сайт собирают в ночь перед сдачей клиенту, бывает? Вот та разница, что я имел ввиду.

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

1. Давайте все же не будем смешивать качество ниже заданного с качеством, при котором проект не может быть принят в принципе - по требованиям законов и стандартов. Не передергивайте :) .

2. В services oriented компаниях, особенно при работе с не-IT клиентами, ситуация нежестко определенных требований практически стандартна - делаем грубый прототип, на нем совместно с клиентом обсуждаем детали. В серьезных продуктах тоже бывает - когда делаем разнообразные proof of concept и feasibility check - есть интересная идея, но что получится на выходе пока толком непонятно.

3. Крайне инфантильный подход. Если вы работаете внутри организации - должны уважать работу своих коллег. Тем более с учетом того факта, что именно PM несет ответственность перед заказчиком и топ-менеджментом (делегируя ее часть членам команды). Не говоря уже о том, что на fixed price проектах до подписания контракта очень редко бывает доступна роскошь оценок bottom-up по готовой функциональной спецификации. Если вы не уважаете PMа и считаете его некомпетентным - не работайте с ним, если вы в принципе готовы отвечать только за себя лично - добро пожаловать во фриланс.

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

1

Я сужу со своей колокольни. Мы работаем сейчас так и мне это нравится:
1. Получили задачу;
2. Трудооценили - отправили оценку заказчику;
3. Если заказчик подтвердил - делим и пишем тесты, иногда тесты согласовываем с заказчиком;
4. Реализуем, реализация подтверждается прохождением тестов;
5. Сдаем заказчику;
6. Обратная связь постоянная, через саппорт, клиент всегда прав, любое желание определяется только сроками и соответственно деньгами.
Как Вы это назовете мне честно говоря все равно.

Теперь к статье, собственно причине спора. Вам она понравилась, мне нет. Основное сравнение agile и waterfall, например "Спор насчёт agile и waterfall на самом деле прост. Моё мнение — agile не плох, просто он слишком часто используется в качестве оправдания для плохого менеджмента на проекте." Теперь у Вас waterfall и нет совсем, так о чем спор? Я так за agile, а Вы?

P.S. Забыл спросить: А как Вы проверяете, что Ваш прототип работает как надо?
Сорри P.P.S. Про то что нет waterfallов попробуйте рассказать главному инженеру, у которого есть план работ на бумажке, подписанный генеральным.
Опять сорри, про ПМ забыл:(
P.P.P.S. ПМ американский, китайского происхождение с 20-летним опытом разработки, когда он говорит - все слушают. Он, кстати, тоже нас слушает (американский принцип открытой двери.) Он ставит приоритеты в задачах, говорит какого клиента облизать полностью, а какого только по пояс, определяет направления разработки новых продуктов. Вроде и все. А, деньги нам еще платит, чуть не забыл:)

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

1. Тот подход, который Вы описываете по пунктам, вполне жизнеспособен, если клиент a) детально представляет себе, что ему нужно и б) готов заниматься микроменеджментом - разбираться (бюджетировать, планировать, принимать) с каждым таском по отдельности. С менеджерской точки зрения такие проекты находятся на нижней ступени сложности - added value от PMа минимально или отсутствует - вернее сказать PM осуществляется заказчиком и риски принимает на себя он. Только не думайте, что все проекты такие - это low-end.

2. Автор толком не сравнивает agile и waterfall, он в основном дискутирует с agile, приплетя waterfall для красного словца.

3. Когда я писал "нету там waterfall-ов" я имел в виду не то что их нет нигде, а то, что их нет в приводимых вами примерах типа "бортовой компьютер автомобиля" (если это конечно не Лада "Калина"). Вы, кажется, не вполне отчётливо представляете себе что такое waterfall. Waterfall - это не жесткая зависимость тасков друг от друга или от внешних поставок, а (немного упрощая) отсутствие итераций.

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

5. Я не за agile, а за common sense. И советую почитать книгу Боэма, на которую я привёл ссылку (книгу пожно найти в сети).

0

Да, нас с Вами не договорится. И по статье - совсем в оффтоп ушли. И по методам работы. У нас, кстати, учат уважать всех клиентов, менеджера, который был сказал, что-то похожее про Калину даже внутри компании - наказали бы точно. Если бы Вы написали, как и что Вы сделали для МАЗа или БЕЛАЗа, как они конвейер останавливали, чтобы конец вашего спринта подождать - можно было бы дискутировать, а так - о чем? Ссылками на книжки бросаться?
Спасибо, за инфу, будет время - гляну.

0

Какая-то каша у вас в голове. Для чего останавливать конвейер для ожидания конца спринта?

0

Не остановят, просто не пустят на конвейер, пока изделие полностью не пройдет весь контроль, без всяких итераций - добавить один винт в крепление коробки после этого или изменить одну строчку в технологической карте практически не возможно. Вот что я имел ввиду. И вся автомобилка тут одинакова, и в России, и в Германии, и в Белоруссии. Слишком дорого стоят ошибки.
Извините, что нечетко написал, просто не подумал, что не все с этим были связаны.

P.S. Даже если есть варианты исполнения, то все они делаются ДО постановки на конвейер, включаются в общее тестирование всего автомобиля и утверждаются целиком. Коврик на 5 см длиннее сделаете и педаль газа западет. Вот почему там чистый waterfall. Да, есть итерация - следующая модель автомобиля через пару лет, или отзыв партии при критической ошибке - тут agile и не пахнет.

0

Я уже потерял нить спора :(
1. Никто же не говорит, что Agile-методологии подходят всем и всегда.
2. В конце итерации должен быть какой-то осязаемый результат: например новая коробка. А не то что мы делаем что-то неделю/месяц/год и в конце срока у нас что-то получается и это что-то идет в продакшн.

1

Я просто не согласен со статьей. На моей практике были проекты чистого waterfall и так было надо, так и проекты agile и так тоже надо и хорошо:), поэтому говорить об эрах и их сменах, с моей точки зрения не совсем правильно.
В моей практике, опять же, waterfall больше был связан с embedded sw developmet, вот я их и привел в пример.
1. Автомобилка - разработка софта часть общего процесса (очень малая), подчинена общим процессам конвейерного (да еще и многократно сертифицированного) производства. Вас туда с идеями из новой, пусть и очень хорошей книжки просто не возьмут. Там свои книги, написанные кровью (пусть громко, но правда).
2. Разработка телекоммуникационного оборудования (модемы, приставки). Очень высокая цена тестирования. Вносишь изменения - едешь в Америку, сажают на месяц в специальную комнату и там проводишь все тестирование. Как вариант - можешь купить это все себе за 100 миллионов баксов и тестировать дома. Тоже был waterfall. Мне понятно почему.
В ЕПАМе и сейчас у меня чисто agile проекты и мне тоже понятно почему, побеседовав с товарищем, я уже принес извинения менеджеру ЕПАМ, за наезд. Оказалось, что по сравнению с другими там очень четко поставленные процессы и понятная методология разработки (мне).
Как работает компания моего оппонента - я не понял. Кто-то решает когда делать тесты, когда нет. Кто-то решает, где минимум качества, приемлемый для клиента, а где маскимум и т.д. Кто-то решает, что прототип хороший или плохой по каким-то своим критериям. В моем понимании - поставленный процесс, это то что максимально исключает человеческое влияние, сегодня этот кто-то здесь работает, а завтра заболел или уволился. Читайте ниже у faketail про гамбургеры. И это не привязано к конкретной методологии, это привязано к ее присутствию вообще.

Anonymous
Anonymous Software Engineering Team Leader в EPAM
1

По моему вы не прочитали статью или что-то недопоняли в ней. Как раз таки основная мысль статьи - "Agile это не игрушка и не панацея на все случаи жизни". Решение, что больше подойдет для конкретного проекта, agile or waterfall, должно быть гибким и учитывать его специфику - тип клиента, уровень разработчиков, тип решаемой задачи и т.п. В статье перечислено то, что по мнению автора будет влиять на принятие решении о выборе методологии. Так с чем вы не согласны?

0

В статье как раз и написано по-разному. И так и сяк. Под Вашей цитатой подписываюсь. См. первый мой пост - статья противоречивая, собрано все в одну кучу.
Неужели в ЕПАМе agile умер?

Anonymous
Anonymous Software Engineering Team Leader в EPAM
0

Никто не умер, ни agile, ни epam :))
Суровая правда жизни в епаме справедливая для большинства проектов заключается в том, что методологию выбирает заказчик, а не мы :)

0

На самом деле, статья не плоха уже тем, что заставила поспорить. Я ее еще раз перечитал - нормально на самом деле. Надо просто название поменять, картинку выкинуть и пару строк:). Но это с моей точки зрения. И опять не понял - причем здесь игры. Хотя это все может просто, чтобы зацепить читателя и привлечь.

На то он и Заказчик, чтоб выбирать, за то все можно попробовать:), даже если и не хочешь.

Спасибо админу за статью.

Александр Флахбарт
Александр Флахбарт программист в BELHARD
1

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

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

Это и позволяет строить сети на тысячи закусочных с примерно одинаковым продуктом на выходе.

Хотя это уже оффтоп, просто объяснил принцип, который излагался автором статьи.

2

Гамбургеры не оффтоп, когда-нибудь мы придем к тому, что код будут писать так же:), это идеал. Статья о том, как прийти к этому идеалу, так что все в тему.

Anonymous
Anonymous Software Engineering Team Leader в EPAM
3

>>Гамбургеры не оффтоп, когда-нибудь мы придем к тому, что код будут писать так же:), это идеал.
Никогда мы не придем к такому и вот почему. Гамбургеры штампуются миллионами - и все они совершенно одинаковы, слеплены по одному процессу. С др. стороны все софтверные проекты уникальны и непохожи друг на друга. У всех совершенно различные требования, ресурсы, бюджеты, клиенты, процессы и т.п.

>>Статья о том, как прийти к этому идеалу, так что все в тему.
Статья как раз и утверждает, что "не бывает двух одинаковых проектов".

0

А кто сказал, что идеал должен быть достижимым? Представьте двух крестьян лет 500 назад, каждый со своей горбушкой хлеба, вот и скажите им, что горбушки могут быть одинаковыми. А теперь один из них инка (если их к тому моменту уже не истребили), а второй с Африки... Поживем, увидим. Кстати, несколько толковых ребят уже приметила нечто общее в столь непохожих процессах (GoF, Ларман и др.)

1

http://www.gamasutra.com/view/feature/4295/the_state_of_agile_in_the_game_.php?page=1
Достаточно интересная заметка в тему: Не все так плохо с Agile ;)

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже