9 пунктов, которые надо сделать до начала разработки игры
Какие вопросы должен задать себе каждый, перед тем, как начать разработку новой игры? Задать вопросы и найти ответы. Эти ответы, будучи задокументированными, образуют фундамент для продуктивной работы над проектом, страхуют от переделок и срывов сроков.
В моем багаже опыта среди прочего, есть два противоположных кейса, по разработке приложения с нуля. Один провальный, второй — нет. В первом случае ни у меня, ни у моих коллег не было опыта подготовительной работы и мы пилили игру, используя эвристический подход, основанный на тематической литературе и здравом смысле. Во втором случае, наученный горьким опытом, я перенял опыт топовой американской компании, чье имя не могу озвучить в рамках договоренностей. Этот подход заключается в качественной подготовительной работе, которая даёт возможность на ранних этапах создать базу для дальнейшей разработки.
Целевая аудитория заметки: stakeholders, product owners, producers, game designers, indie, startups
0. Ожидаемые KPI
Вначале стоит изучить рынок, и понять, чем он дышит. Стоит посмотреть на показатели потенциальных конкурентов: игры топ гроссинга, вновь вышедшие игры — динамику их развития и модель выхода. Имеет смысл понять топовые и средние показатели рынка в разрезе:
Эти данные в открытом виде практически не возможно получить, если у вас нет инсайда. Я могу посоветовать обратится за помощью к знающим коллегам, например на сайте quora.com. На этом ресурсе собралась такая аудитория, которая готова делиться знаниями. Это происходит не быстро, и первый ответ на вопрос «Какой k-фактор у игр жанра HO?» вы получите в течении 2х — 3х недель.
Также такую информацию можно собирать по крупицам на тематических топовых сайтах, которые висят у меня на сайте в закладках слева.
1. GDD — ранняя версия
Документ, в котором уже на начальном этапе прописывается концепция игры:
- Сеттинг
- Основная игровая механика
- Саб-механики игры
- Обвесы для вовлечения, монетизации, ретеншена и виральности
- Игровая экономика и баланс
На этом этапе GDD не содержит полностью расписанных задач, по реализации механик, подготовки интерфейса или создании диалогов для персонажей — это требование к библии игры. Однако в нём чётко прописана модель дневного бонуса, например. Будет ли это накопительный бонус, будет ли он аннулироваться, и на сколько ценные подарки в нем будут. Ваш Продюсер или Геймдиз должен четко представлять каждый компонент игры, его механику и назначение.
2. User Experience Flow
Этот документ отображает все зависимости, связи, блоки, из которых состоит игра. UXF чаще всего состоит из диаграмм и блок схем. Для реализации требуется полностью представить себе игру в голове, затем перенести все её процессы в алгоритм в виде блок схемы.
В начале вы рисуете основной цикл, не углубляясь в детали: начало — прелоадер — логин — дейли бонус — лобби — игра / IAP / социалка и так далее. Затем каждый компонент вы декомпозируете и создаете для него отдельный алгоритм. Чем больше в вашей игре функционала, тем больше разделов будет в вашем UXF.
Для создания таких алгоритмов я использую cacoo.com и gliffy.com, однако вы можете пользоваться любым удобным сервисом, который позволит вам быстро и комфортно рисовать блок схемы. Если будет вдохновение, напишу отдельную статью о создании UXFlow.
3. UI Wireframes
Это документ который предопределяет работу дизайнера интерфейсов на начальном этапе. Начать стоит с карты экранов, а затем кратко описать каждый из них.. Также не стоит пренебрегать мокапами экранов, они точно лишними не будут и помогут понять как вам, так и дизайнеру общую картину игры.
Для составления документа я использую всё те же cacoo.com, gliffy.com и удобный moqups.com.
4. AERM worksheet
Acquisition, Engagement, Retention and Monetization — компоненты игры, которые должны быть продуманы и прописаны до начала работы над игрой. Каждый из этих компонентов следует расписать в разрезе 3х блоков
- Core Loop
- Metagame
- Social Features
В итоге у вас получится такая таблица:
| Core Loop | Metagame | Social Features | |
|---|---|---|---|
| Acquisition | Как вы приобретаете пользователей при помощи ядра игры? | Как метагейм привлекает игроков? | Как социальные компоненты привлекают игроков? |
| Engagement | Как вы вовлекаете пользователей при помощи игровых циклов? | Что будет мотивом для пользователей оставаться в игре? | Что социальные функции делают для вовлечения игрока в игровой процесс? |
| Retention | Как игра возвращает игроков снова и снова? | Как метагейм возвращает игроков? | Какие социальные компоненты игры направлены на возвращение пользователя? |
| Monetization | Как монетизируется игра? | Что стимулирует пользователя платить? | Как социальные обвесы способствуют монетизации? |
Если у вас нет ответа для какого либо блока из этой таблицы, не стоит начинать работу над проектом, и продолжить ресерч.
5. SDD
На сегодня социальные механики нужны во всех областях разработки: от игр до е-коммерс. Это продиктовано высокой стоимостью трафика, который окупается только при высоком k-факторе, хороших виральных механизмах.
В этом документе следует на базовом уровне расписать:
- сети для коннекта и способ коннекта
- способы приглашений
- способы публикаций
- open graph возможности и рейтинг в facebook
- возможности фан-страницы
- принципы создания ссылок для раздачи подарков
- пуши и уведомления
- e-mail рассылки
6. Prototype plan
План рабочих прототипов должен быть основан на экспертной оценке архитектора приложения. В основу плана закладываем «точки не-возврата» по архитектуре и функционалу. Этот план составляется без дат, так как сроки зависят от состава команды и её квалификации.
Формат плана такой:
- # Code Name
- functional list
- critical
- must have
- additionally
7. Art style guide
Краткий обзор художественного стиля игры в виде скетчей, мокапов и примеров колористики. В ASG следует включить:
- концепт-арт, сеттинг, макеты
- цветовая палитра
- шрифты
- примеры интерфейса и его отдельных элементов (кнопки, рамки…)
- эффекты (арт и программные анимации, тени, прочее)
- стилистика персонажей
- примеры фонов
- примеры игровых значков (иконок)
- mood-board
8. TDD
Техническая информация о приложении: архитектура, информация о используемых технологиях, особенностей платформ и прочая техническая информация изначально заносится в технический док.
- технологии клиент/сервер
- платформы и девайсы
- вес приложения
- использование памяти
- разрешения экранов
- скорость работы/загрузки
На составление такой документации достаточно 2х недель работы компетентного геймдиза, одной недели опытного иллюстратора, и нескольких дней планирования архитектора. Это время, затраченное до активной фазы продакшена поможет выбрать лучший формат команды, сэкономить время в процессе разработки, исключить переделки.
Стартапы и инди разработчики зачастую пренебрегают предварительной фазой разработки, что приводит к неудачам и тупиковым ситуациям. Настоятельно рекомендую адаптировать эти 10 пунктов для проекта, который уже находится в стадии продакшена, это сохранить вам деньги и нервы.
Ссылки из теме:
- cacoo.com — рисовать UXF
- gliffy.com — рисовать карту экранов и диаграммы
- moqups.com — рисовать мокапы
- quora.com — узнать инсайд
Программы для геймдева
Делать игры — не так просто как вам затирают на курсах по созданию игр, особенно когда ты работаешь один. Зачастую, чтоб создать хорошую и качественную игру — надо использовать множество программ для арта, программирования, эффектов, планирования, звуков и всего прочего. А еще надо не забывать про работу с движком. Сегодня я вам расскажу о 45 программах и сервисах, которые очень помогут вам в создании игры.
Арт инструменты
Blender
Начнем, пожалуй, с арт инструментов. Первым будет у нас Blender. Мне кажется, эта программа в представлении не нуждается, все знают про блендер. Блендер — многогранная программа, которая включает в себя огромный функционал, начиная от простого 3д моделирования, заканчивая риггингом, анимацией, эффектами и симуляциями. В основном блендер предназначен для 3д моделирования, но если вы очень хотите — можете постараться смонтировать в нем видео.
3DsMax
Дальше у нас идет конкурент Блендера — 3DsMax. Тоже программа для 3д моделирования, но функционала у нее явно поменьше будет, да и интерфейс сложнее. Однако 3дмакс является некоторого рода стандартом индустрии, так что стремитесь на позицию 3д артиста в большую студию — вам надо уметь работать в 3дмаксе.
MagicaVoxel
Ну и давайте закончим с 3д редакторами, последний и самый простой из вышеперечисленных — MagicaVoxel. Программа заточена под создание воксельных моделек и их рендера. Из проблем: при импорте объектов, на которых множество цветов — сетка объекта будет очень искажена. Конечно, это фиксится костылями, но достаточно геморными. В любом случае, лучшего решения для воксельной графики я не нашел. Можете подсказать мне в комментариях.
ZBrush
Но в вышеперечисленных программах работают в основном с хард-сюрфейс моделями. А что насчет персонажей? Для этого создан ZBrush. Весь его функционал сосредоточен на 3д скульптинге персонажей. Однако, для этого крайне рекомендуется графический планшет, так как сделать что-то внятное на мышке будет весьма проблематично.
Artbreeder
Создавать внешность персонажа с нуля довольно проблематично, а рисовать его концепт порой просто нет желания или времени. На помощь приходят нейросети, а точнее сайт Artbreeder. На этом сайте вы можете благодаря нейросетям сделать внешность своему персонажу в считанные минуты. Очень бывает полезно.
PureRef
Продолжая тему концептов: для понимания того, как должна выглядеть визуально ваша игра — нужно составлять мудборд и концепт-документ, который содержит в себе все нужные референсы из других игр, фильмов, или просто картинок из интернета. Составлять такие доски проще и лучше всего в программе PureRef. Поверьте, эта программа очень поможет вам сохранять свою игру в едином тоне.
Substance painter
А теперь, программа для текстуринга. Она единственная мне известная, однако она универсальна, а также является стандартом индустрии. Речь идет о Substance painter. Текстуры в ней, при должных навыках получаются просто отличные, а благодаря нормалям можно даже лоуполи объекты делать высокодетализированными. В общем, к изучению обязательна.
Aseprite
Дальше на очереди у нас — Aseprite. Эта программа создана специально для пиксель арта, и в целом, является одной из самых популярных программ для этого вида рисования. В ней есть удобный инструментарий для анимации, и простого рисования спрайтов, так что если ваша игра в пиксельной стилистике — крайне ее рекомендую.
PyxelEdit
Альтернатива Асепрайту — PyxelEdit. В целом, я не заметил чтоб они как-то координально отличались, но попробуйте оба варианта и выберите для себя любимый.
Adobe Illustrator и Adobe Photoshop
Интерфейсы, конечно, можно рисовать и в двух вышеперечилсенных программах, однако они подойдут разве что пиксельным и воксельным играм. Если вы хотите сделать плавный и красивый интерфейс — вам определенно стоит изучить Adobe Illustrator и Adobe Photoshop. Если иллюстратор поможет вам нарисовать что угодно для вашей игры, будь то логотип или интерфейс, то фотошоп поможет вам конвертировать векторные изображения в растровые, а также фотошоп иногда может пригодится в текстуринге.
Inkscape
Хочется еще дополнить, что если вы очень скупой, то можете вместо иллюстратора использовать Inkscape. Он абсолютно бесплатен, а функционал, при должных навыках, не сильно уступает, особенно если у вас не сильно высокие требования.
HoudiniFX
Эффекты, порой, очень решают то, как будет выглядеть финальный продукт. Лучшим софтом для создания эффектов и пререндеренных разрушений — является HoudiniFX. Я даже не знаю, что про него сказать, кроме как то, что это стандарт индустрии, который используют крупные компании вроде EA, Ubisoft и Naughty Dog. Эффекты из этой программы могут перевернуть восприятие вашей игры.
Cascadeur
Анимация — процесс сложный, особенно когда речь идет о 3д анимации. Однако все меняется, если вы используете Cascadeur. Уникальная фишка этой программы в том, что вы расставляете всего пару контрольных точек для анимации вашего персонажа, а все остальное программа доделает сама. Магия, да и только.
SpeedTree
Деревья и прочую растительность лично мне было всегда проблемно делать. Но это было до того, как я узнал о программе SpeedTree. В этой программе можно быстро и просто делать растительность любого вида, любой формы и цвета. Очень полезно.
Marmoset tools
Еще одна программа — Marmoset tools. Вообще, это программа скорее для рендеринга, и не факт что вам понадобится, однако мне сказали, что в ней очень классно запекать текстуры. Я не уверен в этом на все сто, но в подборку все-же включу. Мало ли нужно будет.
Quixel Megascans и Quixel Bridge
Ну и последняя программа, некоторый эксклюзивчик для ленивых анриаловцев — Quixel Megascans и Quixel Bridge. Это библиотека сканированных из реальной жизни объектов, начиная от небольших пропов, заканчивая целыми кусками земли, которые можно легко вставить в свою игру, и они будут очень реалистично выглядеть. Эти сервисы бесплатны для игр на Unreal Engine. Я крайне не рекомендую использовать эти сервисы для игр на других движках, потому что в других движках нет системы Nanite, и они будут очень сильно нагружать игру. Ну а если же вы соберётесь качать ассеты бесплатно, и использовать их в коммерческих играх на других движках, что-ж, рекомендую к просмотру топ-10 лайфхаков для тюрьмы.
Кодинг
Что-ж, с арт-программами на этом можно закончить, теперь поговорим немного про кодинг. Все мы прекрасно знаем, что для написания кода нужна среда разработки, но какую выбрать? Хотите честно? Вообще не важно, это на ваш вкус и цвет, хоть в ворде код пишите, мне до лампочки. Однако мастодонтом все же является Visual Studio. Многие в ней пишут, и не жалуются, так что если не знаете что выбрать — выбирайте студию — не ошибетесь. Но если вам нужно что-то другое — попробуйте Rider. Он специально заточен под работу с кодом для игр, как на C#, так и C++.
Игровые движки
Ох, теперь наверное самая интересная часть. Игровые движки. Когда только погружаешься в геймдев — сразу встает вопрос, а на чем, собственно, делать игру? Движков огромное количество, но лучших всего 3: Unity, Unreal Engine и Godot. В основном, все на старте бросаются на Unity, якобы потому что он проще в изучении. Возможно, так и есть (хотя по моему опыту, тот же анриал в разы проще, но тут кому как). Можно сказать точно, что на юнити гораздо больше обучающих материалов. Да и коммьюнити у юнити более открытое, чем где либо еще, так что вы всегда сможете найти помощь. Годот-же в основном хорош за то, что он не берет никакого процента с выручки вашей игры, а также он достаточно прост в изучении. В целом, какой движок выбирать — дело ваше, как и в случае со средой разработки. В любом движке можно создать шедевр, при должном подходе.
Музыка
Теперь, поговорим про аудио. Музыку, пожалуй, проще всего и лучше всего писать в GarageBand. Единственный минус, эта программа исключительно на устройства от Apple, так что если у вас нет таких устройств, можно использовать FL Studio. Обе эти программы хороши для написания музыки к вашей игре, и каких-то плюсов или минусов я назвать не могу.
Для записи и обработки голоса, а точнее озвучки, лучше всего подойдет Adobe Audition или его бесплатная альтернатива Audacity. Опять же, эти программы примерно равны по функционалу, когда мы говорим о записи голоса, однако ходили новости, что Audacity продавала данные пользователей третьим лицам. Используйте на свой страх и риск.
Ну и последнее из разряда звуков, а точнее касающееся звуковых эффектов — программа LabChirp. Звуки из этой программы подойдут далеко не каждой игре, но именно вашей могут подойти. В основном, это альтернатива популярному BFXR, но как по мне, он звучит ужасно, и лабчирп показывает гораздо более приятные результаты.
Видеозапись
В одном из своих видео я рекомендовал записывать девлоги, потому теперь мы поговорим о видео. Программы подойдут не только для девлогов, но и для создания синематиков в игре.
Для начала, софт для записи, и тут два варианта: Nvidia ShadowPlay или OBS. Шадоуплэй потребляет гораздо меньше ресурсов, так как за запись отвечает отдельный чип, установленный на видеокартах, однако OBS более гибкая в плане записи, так как вы можете сразу же настраивать сцену для записи, а также стримить с помощью этой программы. Важно: используйте классическую OBS. Всякие кастомные версии использовать не рекомендую, так как они могут быть слегка ограничены, или же нагружать систему сильнее.
Монтаж
Теперь, программы для монтажа. Лично я пользуюсь, и вам советую Adobe Premiere. Он очень прост в освоении, однако на выхлопе можно получить очень хороший результат. А если использовать его в связке с After Effects — то ваше видео может достигнуть высочайшего качества.
Но если же вам не нравится Премьер или Афтер эффектс — попробуйте Davinci Resolve. Он также достаточно мощный для обработки видео, а особенно приятно в нем работать с цветокоррекцией.
Планировка процесса разработки и игрового баланса
Когда ты разрабатываешь игру — важно уметь планировать и распределять задачи для разработки, а также работать с балансом игры. Именно о программах и сервисах, которые в этом помогут и пойдет дальше речь.
Гугл документы или Word. Как бы не было банально, но даже такие простые программы из курса информатики за 8 класс — очень важны при создании игры. Во-первых, надо уметь изложить свои мысли на бумаге в виде концепт- и дизайн-документов, которые вы будете показывать непосредственным инвесторам для вашей игры, если таковые будут. А даже если вы и работаете без инвесторов — важно вести документацию, так как это поможет вам не отбиваться от концепции игры, которая была у вас изначально.
Планировка пайплайна разработки — очень важная вещь. Облегчат планировку вам сервис Trello. В этом сервисе крайне просто составлять списки задач в виде блоков, и перемещать блоки из одной категории в другую. В общем, при постановлении списка задач — крайне полезный инструмент.
Очень часто бывает так, что вот едешь ты в автобусе, а тебе приходит гениальная идея для игрового бестселлера, а ты забываешь ее записать, потому что негде. На помощь в такой ситуации крайне подойдут приложения-блокнотики. Самыми лучшими будут Google Keep и Standart Notes. Второе приложение заявляет, что оно шифрует написанную тобой информацию на своих серверах. Впрочем, преимуществом этих блокнотиков является то, что ты можешь с любого устройства, войдя в свой аккаунт, прочитать свои заметки.
Для построения блок-схем, например, при создании путей интерфейса, можно использовать сервисы Miro и draw.io. Первый будет немного более многофункционален, но если речь идет исключительно о построении схем — оба сервиса хороши, и выполняют свою работу на все 100.
Ну и последний инструмент, который нужен для грамотного проектирования игрового баланса… Excel или Гугл таблицы. В этих программах очень удобно считать циферки урона, защиты, опыта, да и вообще любой статистики в вашей игре, особенно когда механики в вашей игре достаточно комплексные, и требуют тщательной проработки. Поверьте, вам очень пригодятся таблицы с цифрами, когда пойдет речь о балансе в вашей игре.
Прочее
Ну и последняя категория, “прочее”, содержит все программы и сервисы, которые я не знал куда впихнуть, но впихнуть их хотелось.
Написание сюжета
Начнем с ArticyDraft. Эта программа сделана специально для написания сюжета для вашей игры. В ней очень удобно прописывать определенные события в мире вашей игры, характеры и личности персонажей, и много чего еще. Крайне нужна и полезна, если вы делаете упор на интересный сюжет в своей игре.
Системы контроля версий
Дальше будут две системы контроля версий — Git и Perforce. В основном, все предпочитают Perforce, но лично мне он не очень нравится, вот честно. Какой-то он… Мудреный. Git в разы проще, и в целом, меня устраивает. Но как обычно, выбор за вами, потому как разница не сильно велика.
Средство просмотра фотографий
Следующие две программы будут полезны не только в геймдеве, но и в целом при работе с компьютером. Во-первых, это Google Picasa. Реально лучшая программа для просмотра фотографий, рендеров, и чего угодно. Она очень быстро открывает фотографии, красиво их перелистывает, и может увеличивать вплоть до 1000%.
Ручная чистка ПК без боли в заднице
Во-вторых, программка WizTree. Она очень помогает, когда ты хочешь вручную почистить ненужные файлы на компьютере. Вся ее суть заключается в том, что она выводит древо всех файлов на твоем жестком диске, сортирует по размеру и показывает его. Так гораздо проще определять, что весит у тебя больше всего, и что тебе лучше удалить.
Google
Ну и последнее на сегодня, и пожалуй, самое полезное — гугл. Умей гуглить. Серьезно, научись гуглить, желательно даже на английском. Когда ты создаешь игру — у тебя может возникнуть просто куча проблем, затупов, ошибок, крашей, багов и невесть чего еще. Все эти проблемы зачастую можно решить просто правильным запросом в гугл. Это порой спасает очень много нервных клеток.
Ну вот и все на сегодня. Это все программы и сервисы, которые я лично использую, и вам советую.
- Программирование
- Работа с 3D-графикой
- Разработка игр
- Дизайн игр
- Игры и игровые консоли
Бесплатные ресурсы для начинающих инди-разработчиков
Я изучаю гейм-дизайн и разработку игр. Когда я начала создавать свою первую игрушку (гифка оттуда) по мотивам мультсериала «We Bare Bears», то подолгу зависала, чтобы отрисовать фон, кнопочку, анимацию разрушения блока и пр. Часть артов я, по итогу, не использовала, а время на них тратила много.
За полгода я накопила список ресурсов с бесплатными ассетами, персонажами, музыкой, фонами. Эти ресурсы помогают мне экономить по 10-20 часов на создании учебных игровых проектов. Надеюсь, кому-то этот список сэкономит время и позволит создавать атмосферные прототипы быстро.
А еще я завела канал в Telegram: GameDevils, буду там делиться своими находками про разработку игр, историю игр и геймдизайн.
Лирическое отступление про «We Bare Bears»
Мне захотелось создать свою интерактивную версию эпизода «Icy Nights» в стиле пиксельного платформера.В эпизоде есть отсылки на фильмы «Only God Forgives» и «Drive». Там есть неон, бои роботов, любовная линия, двойная жизнь и даже реактивный пылесос.
Когда заканчивается 11 минутная серия, остается ощущение, что это была полнометражка. Хотя в серии есть все заезженные шаблоны из экнш-боевиков, она не выглядит как пародия.1. Itch.io
Это сервис для инди-разработчиков, дизайнеров, художников и прочих около gamedev творческих личностей. Чтобы получить за свое творчество хоть какой-то доширак, многие художник выкладывают свои работы для скачивания бесплатно или за фри-донат. Так они привлекают внимание к своим профилям.
Это мой самый любимый ресурс, у него современный дизайн, есть теги для поиска и много бесплатных ништячков. Я скачивала оттуда tile map, пиксельартные иконки приложений, разный стафф для интерьера.
Tile map (тайл мэп) — большое изображение состоящее из различных картинок; из фрагментов этого большого изображения составляется обстановка в 2D игре.
2. OpenGameArt
OpenGameArt выглядит как динозавр из нулевых. Я сначала подумала, что сайт скорее мертв, но все же зарегистрировалась. Прочекала посты по тегу «2D Art»: художники ежедневно выгладывают арты. Скачивала еще оттуда музыку и звуки, но там нет удобного поиска по звукам.
Блок-схема выбора оптимальной методологии разработки ПО
Как выбрать методологию? Зачастую, когда необходимо принять решение о выборе методологии в голове слишком много разнородной информации и тяжело понять, что именно лучше подойдёт для проекта. В данной статье я представляю блок-схему выбора оптимальной методологии, как некую подсказку, позволяющую обратить внимание на некоторые наиболее важные аспекты.
В первую очередь хочу отметить, что не бывает универсального набора условий для всех ситуаций при выборе той или иной методологии. В каждом случае вы должны ориентироваться на специфику своего проекта. Рассматриваемая блок-схема лишь обозначит главные аспекты и позволит вспомнить особенности основных методологий. Ни в коем случае не призываю относиться к ней, как к единственно правильному руководству по выбору методологии. Тем более не стоит распространять её на такие сложные проекты как создание ОС, авионики самолёта, моделирование ядерных реакций.
Во-вторых, выбрав методологию, не нужно слепо следовать ей. Часто ее необходимо «допилить», адаптировав под свой проект. Что-то можно выкинуть, что-то добавить из других методологий, внести что-то своё. Например, вам никто не мешает использовать такую практику как парное программирование в водопадной модели, если это принесёт вам пользу. На Хабре есть прекрасная статья по адаптации Скрама и Канбана к конкретному проекту, которая хорошо иллюстрирует данный принцип.
В следующей главе я очень кратко расскажу про упоминаемые в статье методологии и модели жизненного цикла, для тех, кто слышит о них впервые. Более подробно про каждую из них можно прочитать в Википедии. Если вы уже знаете их, то можете смело переходить к главе 2: «Разбор блок-схемы».
1. Краткое описание
Модель жизненного цикла – общее описание того, как происходит процесс разработки.
Методология – более детализированный набор правил, практик и принципов, как способ реализации той или иной модели. Например, методология Скрам реализует итеративную модель разработки.
Фреймворк процессов – грубо говоря, это методология, содержащая большое количество правил, но в которой необязательно использовать их все, а можно выбрать только то, что нужно и построить свой процесс разработки. Имеют в своём составе специальные приложения, позволяющие просматривать и редактировать правила. Примеры: RUP, EssUp.
Каскадная модель (или модель водопада, Waterfall) – характеризуется тем, что этапы разработки, такие как: анализ, проектирование, реализация, тестирование, идут друг за другом. Позволяет быстро создавать систему, без дополнительных накладных расходов на организацию процесса разработки. Однако она работает только тогда, когда требования стабильны и не меняются в ходе разработки, т.к. мы сразу описываем все требования, а потом сразу проектируем всю систему целиком.
V-Model — придумана в Германии и США, как способ улучшить каскадную модель для применения в государственных проектах. V-Model имеет специфику проектов для гос органов: фиксированные требования, стоимость и время. Отличие в том, что этап анализа и проектирования связан с этапом тестирования. Например, во время анализа требований одновременно изучаются подходы к тестированию, во время проектирования архитектуры системы разрабатываются высокоуровневые планы и сценарии тестирования, во время проектирования компонентов системы изучаются способы тестирования компонентов и их взаимодействия, создаются сценарии тестирования, пишутся утилиты, помогающие в тестировании, инструкции, скрипты и т.д. Всё это помогает лучше понять требования и спроектировать систему. Однако тут, также как и в каскадной модели, нежелательно, чтобы требования менялись во время разработки.
Спиральная модель (Spiral) – ориентирована на проекты, в которых имеются серьёзные риски. Разработка представляется в виде спирали. Каждый виток спирали – итерация. Виток спирали состоит из четырёх этапов: планирование, анализ рисков, разработка, оценивание заказчиком. В конце каждой итерации решается, стоит ли продолжать проект. Характерной чертой является то, что на этапе анализа рисков создаются прототипы, концепты, модели которые призваны разрешить риск на ранней стадии. Чем дальше движение по спирали, тем больше разработки продукта и меньше прототипов и концептов. Типичное применение такой модели – исследовательские проекты. Является очень дорогой моделью, и не оправдана в системах, где риски незначительны.
Итеративная модель – ориентирована на проекты, где требования могут меняться по ходу разработки. Проект состоит из итераций (от 1-2 до 6 недель). Каждая итерация может включать в себя этап анализа, проектирования, реализации, тестирования. Имеет большие накладные расходы на организацию процесса, чем каскадная модель, однако стоимость исправления ошибки в зависимости от длительности проекта не так высока. Следующие методологии реализуют итеративную модель: Scrum, XP, отчасти Kanban.
Методология Скрам (Scrum) – итерация называется спринтом. Команда состоит из 3 ролей: владелец продукта (представитель заказчика), скрам-мастер (следит за следованием процессу), остальные члены команды. Спринт начинается с митинга планирования, когда команда отбирает и распределяет задачи на итерацию, формируя бэклог спринта. Спринт заканчивается обзором спринта, где проводится демонстрация продукта и митингом ретроспективы спринта, на котором обсуждаются улучшения. Ежедневно проводятся 15-минутные скрам-встречи.
Методология экстремального программирования (XP) – состоит из 12 практик: парное программирование, разработка через тестирование, рефакторинг, простая архитектура, коллективное владение кодом, непрерывная интеграция, заказчик в команде, частые релизы, игра в планирование, 40-часовая рабочая неделя, стандарты кодирования, метафора системы. Обязательно использование всех 12 практик.
Методология Канбан (Kanban) – конвейер задач. Имеет всего 3 правила: визуализация процесса разработки с помощью канбан-доски, ограничение на количество задач на каждом этапе, постоянное измерение производительности команды и улучшения.
Методология RAD (Rapid Application Development) – ориентирована на быструю разработку приложения, итеративно, с максимально простой архитектурой, минимальными издержками на процесс, максимально используя готовые компоненты и мощные инструменты. Имеет ограничение на длительность проекта — 60-90 дней. Мне нравится аналогия с пирожками из полуфабрикатов. Так вот, RAD – когда нужно быстро слепить пирожок из готовых компонентов.
2. Разбор блок-схемы
Стартапы характерны тем, что там, особенно в начальный период, всё строится на энтузиазме. Далеко не всегда люди работают по 8 часов в день. Если им навязать какую то методологию и поставить в определённые рамки, то либо весь энтузиазм угаснет, либо никто не будет соблюдать правила. Например, довольно глупо ожидать, что инициатор стартапа придёт утром вовремя на скрам-митинг, после бурной ночи кодинга. В дальнейшем, когда всё стабилизируется, можно перейти к использованию подходящей методологии.
Каждый проект имеет риски. Однако в данном случае имеются в виду риски настолько серьёзные, что заранее не известно, можно ли будет вообще реализовать систему. Если такие риски присутствуют, то, скорее всего, вы начнёте разработку с прототипов, концептов, моделей и т.п. чтобы выяснить принципиальную возможность задуманного. В таком случае для вас наиболее оптимальной моделью будет спиральная модель. Типичный пример применения этой модели – исследовательские проекты. Но только исследовательскими проектами применение этой модели не ограничивается.
Пример из реальной практики в области розничной торговли: нам необходимо было разработать мобильное приложение, которое должно было активно взаимодействовать с определённым оборудованием по Bluetooth. Это были считыватели различных карт, различные виды принтеров и сканеры штрих кодов. Нам было не известно, возможно ли это вообще сделать на мобильной платформе. Поэтому мы начинали с прототипов и концептов, в которых пытались выяснить принципиальную возможность взаимодействия с оборудованием и существующие ограничения. Потом мы встречались с заказчиком, демонстрировали то, что получилось и обсуждали обходные пути для того, что не удалось реализовать.
Если же в вашем случае нет таких серьёзных рисков, то встаёт следующий вопрос: будут ли требования меняться. Если ваши требования заранее хорошо известны, и вы уверены что в процессе разработки заказчик не будет вносить сколь-нибудь существенные изменения, то тогда вам следует выбрать каскадную модель разработки. Я рекомендую выбирать каскадную модель, когда у проекта небольшая длительность. В случае чётких и неизменных требований вкупе с небольшой длительностью, каскадная модель в сравнении с итеративной моделью даст меньше накладных расходов на процесс. На всём этапе реализации программистов ничто не будет отвлекать от написания кода: ни необходимость срочно исправлять баги из прошлой итерации, ни бесконечные митинги и релизы.
Однако в случае длительных проектов, каскадная модель будет плохо работать. Несмотря на то, что риски изменения требований отсутствуют, присутствует технические риски. Например, если вы разработали некорректную архитектуру, выбрали не те технологии и инструменты, не рассчитали требуемую производительность и т.п., с большой долей вероятности вы узнаете об этом в конце, и времени на исправление может не остаться. Чем дольше длится проект, тем выше цена исправления ошибки. Если на начальном этапе рефакторинги и кардинальные изменения кода даются легко, то под конец проекта, сделать это уже довольно-таки «болезненно».
Пример из практики: нам необходимо было реализовать мобильное приложение, которое делало бы абсолютно то же самое, что и такое же приложение для настольного компьютера. Таким образом, требования были известными и неизменными на всём протяжении проекта.
Следующий вопрос: сложные ли требования. Вопрос опять-таки не однозначный и зависит от проекта. Кода вы начинаете проект, иногда бывает полезным на этапе анализа и проектирования продумать, как вы будете тестировать. Это может помочь раньше выявить потенциальные проблемы и лучше реализовать архитектуру, проработать требования и т.п. Когда требования сложные, рекомендуется тщательно продумать все сценарии тестирования, и ещё на этапе анализа и проектирования разработать подходы к тестированию, тест-планы и тест-кейсы. В таком случае нам приходит на помощь модель V-Model, являющаяся разновидностью каскадной модели.
Применение V-Model там, где требования достаточно простые приведёт к тому, что система окажется дороже. Более того V-Model критикуют за то, что она порождает множество документации и бюрократии и служит в реальности не для того, чтобы создать качественный софт, удовлетворяющий заказчика, а для того, чтобы в конце проекта доказать, что система работает как и требовалось изначально, вместо того, чтобы действительно разработать то, что ему было нужно.
Формализованный подход заключается в том, что все процессы жизненного цикла приложения детально регламентированы. Это необходимо в сложных больших проектах с большой командой.
Примером могут служить системы, от которых зависят жизни людей: медицина, транспорт, энергетика. Обычно подобные системы разрабатываются в соответствии с отраслевыми стандартами, многократно тестируются, подлежат лицензированию. Лёгкие методологии в подобных системах не работают. Как вы знаете, в них живое общение предпочтительнее документации, но, например, если ваше приложение будет тестироваться несколько раз разными командами, то лучше, если этот процесс тщательно задокументирован. Если в команде десятки человек, то никакой владелец продукта (представитель заказчика по терминологии скрам) не сможет им всем постоянно разъяснять требования.
Таким образом, если вам требуется формализованный подход, то вашим выбором станут такие методологии как RUP, OpenUp, EssUp. Такие методологии являются больше чем методологиями и правильнее их называть фреймворки процессов. Они изначально созданы для итеративной модели, однако, их можно путём модификаций использовать и в каскадной модели.
Если же нам формализованный подход не нужен, тогда мы будем использовать, так называемые, гибкие методологии. Скорость или качество? На самом деле здесь подразумевается немного более сложная формулировка: продуктивность или инженерия?
Под продуктивностью понимается наиболее быстрый процесс добавления функционала в приложение. Под инженерией подразумевается высокий уровень организации разработки, новаторские подходы и сложные приёмы, которые могут быть применены только опытной командой. Я говорю о таких практиках экстремального программирования как разработка через тестирование, непрерывная интеграция, парное программирование и т.п. Особенность экстремального программирования заключается в том, что обязательно нужно использовать все 12 практик, только тогда эффект от них становится максимальным. Если вы не будете использовать какую-то практику, она обязательно потянет за собой все остальные. Например, если вы откажетесь от юнит тестов, тогда вы не сможете делать частые рефакторинги, без рефакторингов вы не сможете обеспечить простую архитектуру (как мы знаем простую архитектуру разработать сложнее, чем сложную) и т.п.
Однако вы можете использовать практики экстремального программирования в других методологиях, более того, это может быть очень полезным. Например, вы можете использовать парное программирование в Скраме, чтобы помочь новичкам быстрее влиться в проект. Таким образом, экстремальное программирование может обеспечить высокое качество за счёт более высокого уровня инженерии, но при выборе этой методологии проект может получиться дороже. Также для успешного применения обязательно требуется команда, уже имеющая опыт использования данной методологии.
Если же вам нужна максимальная продуктивность, то также есть варианты. Скрам ориентирован на постоянное усовершенствование процесса. Для этого у него есть митинг ретроспективы, которые проводятся в конце спринта. Также во время обзора спринта обсуждается, что было сделано хорошо, что плохо и что улучшить. Если у вас опытная команда, хорошо отлаженный процесс и вам в принципе не нужны совершенствования, то следование методологии Скрам будет отнимать у вас слишком много времени, которое вы могли бы потратить с большей пользой. Например, по Скраму, если спринт длится 1 месяц, то обзор спринта должен занимать 4 часа и ретроспектива спринта – 3 часа. Плюс к этому есть планирование спринта, длящееся 8 часов и ежедневные Скрам митинги по 15 минут.
Если у вас, к примеру, неслаженная команда, либо используются нопробованные технологии или незнакомая сфера применения вашего приложения или всё вместе взятое, то выбор методологии Скрам может быть прекрасным решением. Когда начинается новый проект, можно начать использовать Скрам, а когда процесс станет более отлаженным, архитектура стабилизируется, потребность в постоянных улучшениях отпадёт, то можно перейти к другой методологии, например, Канбан.
Если совершенствования не нужны и всё, что нужно, это сконцентрироваться на выполнении задач, то хорошо подойдёт RAD или Kanban. RAD имеет много общего с agile методологиями, но в нём есть существенное ограничение на длительность проекта. Желательно не более 60-90 дней. Канбан похож на некий беспрерывный конвейер, который может длиться бесконечно. Он хорошо работает на проектах поддержки, но плохо там, где требуется разработать сложную архитектуру, т.к. ориентирован на быстрое добавление фич в приложение. Под фичами имеется в виду кусок функциональности, который виден пользователю и непосредственно решает какую-либо его задачу. Например, логирование, оптимизация и масштабируемость пользователю не видны, это не фичи в терминологии Канбан. А вот новая страница, отчёт, дополнительные фильтры в поиске— это то, что видно пользователю и является фичей.
Источники:
1. Dr. Winston, W. Royce. Managing development of large software systems. 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. W Boehm, A spiral model of software development and enhancement. 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf
3. W Boehm. Spiral Development: Experience, Principles, and Refinements. 2000. http://www.sei.cmu.edu/reports/00sr008.pdf
4. С. Белоусова, И. Бессонова, Руджеро Гиляревский. Введение в программные системы и их разработку. НИУ ВШЭ. http://www.intuit.ru/studies/courses/3632/874/info
5. К. Швабер, Д. Сазерленд.Скрам Гайд. Исчерпывающее руководство по Скраму: Правила игры.
http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100
6. Rational Unified Process. Best Practices for Software. Development Teams. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Introduction to OpenUP. http://epf.eclipse.org/wikis/openup/
7. Х. Книберг, М. Скарин. Scrum и Kanban: Выжимаем максимум. InfoQ. 2010
8. К. Ауэр, Р. Миллер. Экстремальное программирование. Постановка процессов. – СПб.: Питер: 2004
9. Экстремальное программирование – реальность и мифы. skipy.ru/philosophy/xp.html
10. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, USA, 2003
11. James Christie. The seductive and dangerous V Model.
http://www.clarotesting.com/page11.htm
12. Adel Alshamrani. A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental/Iterative Model. http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model- Управление проектами
- Agile