Удосконалення процесів в магазинах GameDev для однієї людини


11

Як хобі-програміст, як я можу включити у свої процеси процес, що нагадує постійне вдосконалення, як ретроспектива Agile?

Я спробував пункти з трьох хороших / поганих речей в кінці кожного проекту, але я вважаю, що цього недостатньо. І я відчуваю, що спринтна ретроспектива - це надмірність. Де баланс? Як можна і чи потрібно відкривати двері для постійного вдосконалення процесу?

Чи, можливо, це запитання має бути запущено на веб-сайті бета-версії Project Management Stack Exchange ?

Відповіді:


6

Оскільки це особистий проект, ви повинні бути дуже обережними, щоб не заграти в процесі. Хоча постійне вдосконалення дуже бажано, подумайте про вибір елементів Lean і Agile, які філософськи відповідають простоті вистави "людина-людина".

У Scrum та багатьох інших системах спринт-ретроспективи вигідні, оскільки вони дають час команді визначити вдосконалення. У Lean часто фокусується на вирішенні проблеми в міру її виникнення, і я думаю, що саме тут ви могли б отримати велику користь.

Виявивши неприємний біт коду чи проблеми, позначте його та скористайтеся часом, щоб зробити наступне:

  1. Подивіться, де проблема знаходиться
  2. Подивіться на взаємодіючі елементи та системи
  3. Знайдіть швидке рішення (те, що працює, що ми зазвичай робимо і на чому зупиняємося)
  4. Визначте першопричину (запитайте 5, чому це )
  5. Створіть більш втілене (можливо, навіть стандартизоване) рішення або план рішення (можливо, щось, що має бути реалізовано після цього проекту або спринту)

Отже, це взято з п'яти золотих правил управління Gemba і відповідає, щоб відповідати вашому сценарію. До певної міри це все ще не надто застосовно. Ваш пробіг буде змінюватися, і вам доведеться адаптуватися; але, є гарна новина: все це частина Lean!

Вам потрібно адаптувати будь-які процеси, які можна визнати "правильними". Це буде те, що вам доведеться постійно вдосконалювати, само по собі.

Сподіваюся, це має сенс. Я можу надати більш конкретні посилання та коментарі, якщо ви хочете.

EDIT (у відповідь на запитання в коментарях):

Для початку я пропоную відвідати LeanBlog.org . Ви можете прочитати цю статтю спочатку. Це короткі і повні жалюгідні цитати. Більшість йде про охорону здоров'я; але, ви дійсно швидко побачите, як це стосується і ігор.

Не для того, щоб зазублювати власний ріг, але я написав статтю про gamasutra про стандартизовану роботу, і вона має чудові ресурси в розділі коментарів, а також ідеї. Ви можете знайти його тут.

Я б дуже рекомендував переглянути блог Menlo Innovation . Більшість того, про що вони говорять, стосується великих компаній; але, ви повинні мати можливість адаптувати його.

Мені буде цікаво дізнатися ваші результати через кілька місяців :)

Я сподіваюся, що ці посилання допоможуть!


Будь ласка, надайте посилання. Також я дуже хотів би прикладу цього.
ashes999

0

Хоча на роботі ми використовуємо JIRA для цього типу матеріалів, я адаптував його версію для власного використання в геймеді в домашніх умовах. Це може бути, а може не бути системою, яка працює для вас, але я все одно додам її:

  1. Дістаньте декілька індексів і десь зберігайте їх - кілька стосів на столі просто чудово. Позначте ці палі "Не розпочато", "Не триває", "Заблоковано", "Покращення потреб" та "Завершено".
  2. Якщо я думаю про завдання, яке потрібно виконати, я негайно записую його на індексну карту і даю оцінку складності / складності
  3. Якщо завдання, над яким я зараз працюю, заблоковане, я записую причину, чому на спині
  4. Якщо завдання не є блокатором, не виконайте це, поки не доведеться (або поки ви не будете розблоковані / виконуються завдання)
  5. Якщо всі ваші завдання знаходяться на етапі вдосконалення потреб або завершення, починайте працювати над тими, які потребують удосконалення.
  6. ????
  7. Прибуток!

Моє питання не в тому, як реалізувати спритний та управління проектами; це налаштування моїх існуючих процесів розвитку ігор. Ура, хоча.
ashes999
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.