Cải thiện quy trình trong Cửa hàng GameDev một người

Là một lập trình viên sở thích, làm thế nào tôi có thể kết hợp một quy trình giống như cải tiến liên tục như quá trình hồi tưởng của Agile trong các quy trình của mình?

Tôi đã thử các mục đạn của ba điều tốt / xấu vào cuối mỗi dự án, nhưng tôi cảm thấy nó không đủ. Và tôi cảm thấy rằng một hồi tưởng chạy nước rút là quá mức cần thiết. Số dư ở đâu? Làm thế nào tôi có thể và nên mở cánh cửa để cải tiến quy trình liên tục?

Hoặc có lẽ câu hỏi này nên có trên trang web beta Exchange Management Stack Exchange ?

Vì đây là một dự án cá nhân, bạn phải rất cẩn thận để không bị sa lầy trong quá trình. Mặc dù cải tiến liên tục là rất mong muốn, hãy xem xét lựa chọn các yếu tố từ Lean và Agile phù hợp về mặt triết học với sự đơn giản của chương trình một người đàn ông.

Trong Scrum và nhiều hệ thống khác, hồi cứu chạy nước rút là có lợi, vì chúng cung cấp thời gian cho một nhóm để xác định các cải tiến. Ở Lean, thường xuyên tập trung vào giải quyết vấn đề khi nó phát sinh và tôi nghĩ đây là nơi bạn có thể hưởng lợi rất nhiều.

Khi bạn xác định một chút mã khó chịu hoặc một vấn đề, hãy gắn cờ và dành một chút thời gian để làm như sau:

1. Nhìn vào nơi vấn đề cư trú
2. Nhìn vào các yếu tố và hệ thống tương tác
3. Tìm một giải pháp nhanh chóng (một cái gì đó hoạt động, những gì chúng ta thường làm và dừng lại ở)
4. Xác định nguyên nhân gốc rễ (hỏi 5 lý do tại sao )
5. Tạo ra một giải pháp hoặc kế hoạch đầy đủ hơn (thậm chí có thể được chuẩn hóa) cho một giải pháp (có thể là một cái gì đó sẽ được thực hiện sau dự án hoặc chạy nước rút này)

Vì vậy, điều này được lấy từ năm quy tắc vàng của quản lý Gemba và đấu tranh để phù hợp với kịch bản của bạn. Ở một mức độ nào đó, nó vẫn không thể áp dụng được. Số dặm của bạn sẽ thay đổi và bạn sẽ phải thích nghi; nhưng, có một tin tốt: đó là một phần của Lean!

Bạn cần điều chỉnh bất kỳ quy trình nào bạn có thể thấy là "phù hợp". Đây sẽ là điều bạn sẽ phải liên tục cải thiện, trong và của chính nó.

Tôi hy vọng điều đó đúng. Tôi có thể cung cấp các tài liệu tham khảo và bình luận cụ thể hơn nếu bạn muốn.

EDIT (để trả lời câu hỏi trong ý kiến):

Để bắt đầu, tôi khuyên bạn nên truy cập LeanBlog.org . Bạn có thể muốn đọc bài viết này đầu tiên. Nó ngắn và đầy những trích dẫn sâu sắc. Hầu hết là về chăm sóc sức khỏe; nhưng, bạn sẽ thực sự nhanh chóng thấy nó cũng áp dụng cho các trò chơi.

Không phải tự mình lấy sừng, nhưng, tôi đã viết một bài báo về gamasutra về công việc được tiêu chuẩn hóa và nó có một số tài nguyên tuyệt vời trong phần bình luận cũng như ý tưởng. Bạn có thể tìm thấy nó ở đây.

Tôi rất muốn đề nghị kiểm tra blog của Menlo Đổi mới . Hầu hết những gì họ nói là áp dụng cho các công ty lớn hơn; nhưng, bạn sẽ có thể thích nghi với nó.

Tôi muốn tìm hiểu kết quả của bạn sau một vài tháng :)

Tôi hy vọng những liên kết giúp đỡ!

Mặc dù tại nơi làm việc, chúng tôi sử dụng JIRA cho loại công cụ này, tôi đã điều chỉnh một phiên bản của nó để sử dụng cho gamedev tại nhà. Nó có thể hoặc không thể là một hệ thống phù hợp với bạn, nhưng dù sao tôi cũng sẽ thêm nó vào:

1. Nhận một số thẻ chỉ mục và một nơi nào đó để giữ chúng - một vài cọc trên bàn làm việc tốt. Đánh dấu các cọc này "Chưa bắt đầu", "Đang tiến hành", "Bị chặn", "Cần cải thiện" và "Hoàn thành".
2. Nếu tôi nghĩ về một nhiệm vụ cần hoàn thành, tôi lập tức viết nó xuống một thẻ chỉ mục và ước tính độ khó / phức tạp
3. Nếu một tác vụ tôi hiện đang làm việc bị chặn, tôi viết lý do tại sao ở mặt sau
4. Trừ khi tác vụ là một trình chặn, đừng làm điều đó cho đến khi bạn phải (hoặc cho đến khi bạn ra khỏi các nhiệm vụ đang được bỏ chặn / đang tiến hành)
5. Nếu tất cả các nhiệm vụ của bạn đang ở giai đoạn Cần cải thiện hoặc Hoàn thành, hãy bắt đầu làm việc với những nhiệm vụ cần cải thiện.
6. ????
7. Lợi nhuận!