Pull to refresh

Еще одна методология: Стаханов

System Analysis and DesignGame development


Общие принципы


  1. Задания создаются и пишутся для удобства исполнителей.
  2. Результатом работы геймдизанеров являются полные и понятные даже новичкам задания.
  3. Исполнители читают задания и меняют их статус. (они пишут код, а не задания)
  4. Долго висящие задачи — удаляются (надо будет — еще раз заведем)




Общий стиль описания


  1. Командный: что, кому и когда нужно сделать. Никаких двусмысленностей и догадок быть не должно.
  2. Только полные фразы. С подробным (пошаговым) описанием действий.
  3. Фраза вырванная из контекста должна оставаться осмысленной.
  4. Все параметры должны иметь цифровые значения (количество элементов, размеры картинки, длинна строки)
  5. Все списки должны быть пронумерованны (легче делать Check List)
  6. Длинные списки должны разбивать на смысловые группы по 3 элемента
  7. Надписи на рисунках и в тексте должны совпадать дословно. Если они не совпадают — значит это разные надписи.
  8. Пристальное внимание уделяется ошибкам и крайним ситуациям (неверные символы, длинные строки, потеря связи, неправильное время, быстрые и беспорядочные тапы)


Описание функционала


  1. как его запустить/вызвать?
  2. полный список всех вариантов ответов
  3. полный список реакций на каждый вариант действий
  4. подробный список всех ошибок, которые могут возникнуть
  5. описание крайних ситуаций (длинные строки, потеря связи и т.д.)
  6. как его закрыть, куда переходить после него?


Типы заданий


Введение нового функционала

  1. Создается большая задача, которая назначается на геймдизайнера (ответственного за введение функционала)
  2. Геймдизайнер разбивает функционал на подзадачи и расписывает каждую из них.
  3. Любая подзадача должна выполняться одним человеком меньше чем за один день.
  4. В том числе и такие задачи как оценка сроков, составление списка, исследование технологий и т.д.

Короткая задача:

  1. ссылка на общую(большую задачу)
  2. если в задаче упоминаются элементы или ссылки на другие задачи — они должны быть указанны
  3. любой список должен быть пронумерован
  4. длинные списки должны разбиваться на тройки (группировка элементов по смыслу)
  5. короткая задача не должна содержать ссылки на внешние документы или картинки: все необходимое должно быть указано в самой задаче (внешние источники могут пропадать)

Задача по исправлению:

  1. Как воспроизвести (быстрый способ) — возможно потребуется тестовый уровень или что-то еще.
  2. Что именно работает неправильно
  3. Как должно работать правильно (как проверить что баг исправлен)


Участники



Продюсер

  1. назначает задачи геймдизайнеру (в статусе Design Notes)
  2. просматривает и вносит замечания в расписанные геймдизайнером задачи
  3. подписывается на задачи расписанные геймдизайнером для их отслеживания
  4. проверяет список задач Waiting Other и вмешивается если необходима помощь

Геймдизайнер

  1. расписывает задачи (короткие задания не более одного дня в виде подзадач) поставленные продюссером
  2. согласовывает расписанный дизайн с продюссером и главным программистом.
  3. окончательно сформировав задание и согласовав, меняет статус Design Notes -> Tech task
  4. выбирает задачу Resolved и проверяет ее исполнение
  5. если условия задачи не выполненны — задача переоткрывается
  6. если условия выполнены — задача закрывается Resolved -> Closed
  7. в случае возникновения новых условий (а теперь стрелочку правее, тут быстро) — создается новая задача со ссылкой на предыдущую.
  8. Если все подзадачи (расписанные геймдизайнером) закрыты — можно закрывать глобальную задачу, поставленную продюссером.

Программист

  1. когда текущая задача завершена, закрывает ее и начинает выбирать новую
  2. сначала необходимо проверить отложенные задачи Waiting Other — можно ли их продолжить?
  3. если не удалось найти среди отложенных, выбираем новые только среди Tech Task со старшим приоритетом, назначенным на программиста.
  4. если таких задач больше 3х — он просит геймдизайнера отранжировать задачи по приоритету (High — не больше 3х)
  5. выбранное задание изучается
  6. если задание непонолное или непонятно написано — оно отсылается геймдизайнеру обратно
  7. если все понятно — меняет статус в In Progress и начинает выполнять задание
  8. когда выполнить задание становится невозможным — выставляется статус Waiting Other
  9. задача откладывается — это сигнал для геймдизайнеров и продюссера о необходимости помочь.
  10. если задача закончена — выставляем статус Resolved (можно изменить через комментарий в коммите репозитория)
Tags:jiragamedesignтз на программирование
Hubs: System Analysis and Design Game development
Rating +8
Views 8.7k Add to bookmarks 85
Comments
Comments 9

Popular right now

Project Manager
from 34,200 to 60,000 €BETBYРигаRemote job
Senior Software Engineer [Security team]
from 5,000 to 6,500 $Coins.phRemote job
Senior C++ Engineer
to 230,000 ₽ItivitiСанкт-Петербург
Full Stack Developer
from 2,200 to 2,600 $ActsoftRemote job
Senior Software Engineer C++
from 7,500 to 11,500 $MotionalСингапур

Top of the last 24 hours