One-Man GameDev 상점의 프로세스 개선

취미 프로그래머로서 프로세스에 Agile의 회고와 같은 지속적인 개선 프로세스를 어떻게 통합 할 수 있습니까?

각 프로젝트가 끝날 때 세 가지 좋은 / 나쁜 것들의 총알 항목을 시도했지만 충분하지 않다고 생각합니다. 그리고 스프린트 회고는 지나친 것 같습니다. 균형은 어디에 있습니까? 지속적인 공정 개선을 위해 어떻게 문을 열 수 있습니까?

아니면이 질문은 베타 프로젝트 관리 스택 교환 사이트에서 진행되어야 합니까?

이 프로젝트는 개인적인 프로젝트이므로 처리 과정에서 혼란에 빠지지 않도록 매우 조심해야합니다. 지속적인 개선이 매우 바람직하지만, Lean과 Agile에서 원맨 쇼의 단순성과 철학적으로 일치하는 요소를 선택하는 것이 좋습니다.

스크럼 및 기타 여러 시스템에서 스프린트 회고는 팀이 개선 사항을 식별 할 수있는 시간을 제공하므로 유익합니다. 린 (Lean)에서는 문제가 발생할 때 문제를 해결하는 데 중점을두고 있으며, 이것이 바로 여러분이 큰 혜택을 얻을 수있는 곳이라고 생각합니다.

불쾌한 코드 나 문제를 식별 할 때이를 플래그로 지정하고 잠시 다음을 수행하십시오.

1. 문제가있는 곳을보십시오
2. 상호 작용하는 요소와 시스템을보십시오
3. 빠른 해결책 찾기 (작동하는 것, 일반적으로하는 일 및 멈추는 것)
4. 근본 원인 파악 ( 5 가지 이유 )
5. 보다 충실한 (아마도 표준화 된) 솔루션을 생성하거나 솔루션 계획 (이 프로젝트 또는 스프린트 이후에 구현할 것)

따라서 이것은 Gemba 관리의 다섯 가지 황금 규칙에서 가져 왔으며 시나리오에 맞게 조정되었습니다. 어느 정도까지는 여전히 적용 할 수 없습니다. 마일리지가 다를 수 있으며 적응해야합니다. 그러나 좋은 소식이 있습니다. 이것이 린의 모든 부분입니다!

"적합한"프로세스를 찾으십시오. 이것은 지속적으로 개선해야 할 것입니다.

나는 그것이 의미가 있기를 바랍니다. 원하는 경우 더 구체적인 참조 및 의견을 제공 할 수 있습니다.

편집 (의견에 대한 질문에 대한 답변으로) :

시작하려면 LeanBlog.org를 방문 하십시오 . 이 기사를 먼저 읽으십시오 . 짧고 피투성이 따옴표로 가득합니다. 대부분은 건강 관리에 관한 것입니다. 그러나 게임에 어떻게 적용되는지 빠르게 알 수 있습니다.

내 자신의 경적을 울리지 말고 표준화 된 작업 에 대한 가마 수트라에 관한 기사를 썼고 의견 섹션과 아이디어에 대한 훌륭한 자료가 있습니다. 여기에서 찾을 수 있습니다.

Menlo Innovation의 블로그를 확인하는 것이 좋습니다 . 그들이 말하는 것의 대부분은 대기업에 적용됩니다. 그러나 적응할 수 있어야합니다.

몇 개월 후 결과를 찾는 데 관심이 있습니다. :)

그 링크가 도움이 되길 바랍니다!

직장에서 우리는 이러한 유형의 물건에 JIRA를 사용하지만 집에서 gamedev에 사용하기 위해 JIRA 버전을 조정했습니다. 그것은 당신에게 맞는 시스템 일 수도 있고 아닐 수도 있지만, 어쨌든 추가 할 것입니다.

1. 책상 위에 몇 개의 더미가 잘 작동합니다. 이 더미를 "시작되지 않음", "진행 중", "차단됨", "개선이 필요함"및 "완료"로 표시하십시오.
2. 완료해야 할 작업을 생각하면 즉시 색인 카드에 기록하고 난이도 / 복잡함을 추정합니다.
3. 현재 작업중인 작업이 차단 된 경우 이유를 다시 작성합니다.
4. 작업이 차단되지 않는 한 필요할 때까지 (또는 차단되지 않은 / 진행중인 작업이 종료 될 때까지) 수행하지 마십시오.
5. 모든 작업이 개선 필요 또는 완료 단계에있는 경우 개선이 필요한 작업을 시작하십시오.
6. ????
7. 이익!