As an independent developer or a small development team, due to the low cost of direct communication, too much project management process makes the development process cumbersome, in addition to limited resources, small development teams rarely have full-time project managers to control the progress of the project, so that the standardized project management method is often ignored in small team development.
Therefore, this article has compiled some project management methods that I personally believe are relatively practical for independent teams, and I hope to inspire you.
The method mentioned in this article is mainly derived from the project management course Production Practicum learned in the NYU Game Center, a simple summary combined with personal practical experience, and cannot be used as a rigorous and comprehensive "guide", hoping to use this to throw bricks and stones, welcome to share what you think is practical project management methods.
The core of project management can be summarized as being clear at all times who should do the most in the moment and why, and minimizing the ambiguity of the unknown. The project development is divided into three stages: Pre-Production (pre-development), Production (under development), and Post-Production (post-development). So what are the important project management methods in each phase?
at the beginning of the project, the first thing that needs to be determined is the development method to be adopted by the team, whether it is waterfall development or agile development. traditional waterfall development emphasizes making each stage perfect before moving on to the next. from requirements analysis to design, from design to development (programs, art, etc.) to testing. the waterfall model emphasizes documentation, and there is no iteration and feedback in the early stage, so it is very inflexible for projects with unclear requirements and easy to change.
In game development, I personally believe that good games are not conceived but changed, all player-centric is the root of good games, and non-commercial game demand changes are commonplace. Therefore, agile development that emphasizes small versions and frequent iterations and tests (such as the Scrum model) may be more suitable for games, not only for small teams, but also for the industry. Agile development is highly flexible, emphasizing face-to-face and timely communication (such as Daily Check-in daily station meetings, etc.), rapid iteration (sprint-guided short-cycle development), regular packaging and runnable version timely testing, and so on. The methods discussed later in this article are basically some of the methods commonly used in agile development.
Project Summary visually summarizes the project documentation
An important part of the project that is often overlooked in independent development teams is project estimation, and effective project estimation can help us better control the overall situation, correctly assess task priorities, clarify progress, minimize unknown ambiguity, and so on. At the beginning of the project, the first item expected was the Pitch Document, which can probably be called a creative document, which briefly describes the core content of the game in the least amount of space. In the process of writing down the ideas, designers can not only help them clarify the prototype of ideas, but also the core guidance of the project development direction after the project is established. Pitch Doc needs to be kept up to date as the project changes and is an important reference document when introducing the game to others. This kind of document is about 2-5 pages, mainly solving the following problems:
what do you want to do?
- Overview: An overview of the game in one sentence
- Platform & Genre: Target platforms and game types
- Gameplay: Overview of the core gameplay (can be illustrated, see 1-Page Design Doc below)
- Feature: Why make this game? / Why is it a worthwhile project? /What are the distinctive features? ... (If it is a commercial project, a simple competitor analysis may be required)
- similar products: in order to make it easier to understand the game more quickly, a brief mention of similar works of the same type can be briefly mentioned
- what does it look like?
- art direction: show concept design or reference drawings, etc
- what are you going to do?
Team: Briefly describe the division of labor among team members and their strengths (why the project can be done well)
Scope, Budget, Timeline: Briefly describe the project size, budget, and timeline
In addition to Pitch Doc, some necessary project documentation will be added in subsequent developments. But in agile development, cumbersome traditional design documents are rarely used as a medium of communication because of the high cost of communication and no one wants to read a manual of tens of pages. The following two are the more common methods used today when the necessary design documentation is required in the industry:
simply put, turn traditional documents into online documents, easy to retrieve and update, and easy to co-edit. it is typically used as a query archive and not as a development guidance document.
1-Page Design Doc is a new form of improving document usage and communication efficiency. One of the original sources of inspiration was architectural drawings, emphasized in a minimum of length (only one page!). ) and intuitive illustrations to interpret the design. The length of a page greatly reduces the pain of developers reading cumbersome text, and makes it easier to communicate and update in a timely manner, and the illustrations are easier to show the relationships and dynamic changes between systems than the text. 1-Page Design Doc Our more common type may be the Flow Chart interface flowchart commonly used in UX design, but it can also be used in other designs, such as card design, core game play analysis, etc.
(I stumbled upon a designer's personal website on the Web with quite a few examples of using 1-Page Design Doc, see http://bobbyross.com/tutorials/)
Project Plan Project Plan
The project schedule can be regarded as the core document in project management, the small team due to lack of manpower and do not have the energy to maintain a large number of documents, so in my own project, I put the timeline, milestones, and Backlog, Sprint task schedule in this table. In this way, the files I maintain on a daily basis are basically project plan and the Build Note that will be mentioned later. The following image is the schedule I am currently using for my project, and you can see that the top horizontal axis is the time node division and milestone related content.
The time point is related to the work density, my table is about half a week, if the work density is high, it can be divided into finer. The first column on the left vertical axis is the large category (design/art/program/music, etc.), the second column divides each category into different Sprint themes and backlogs, and the three or four columns are specific tasks written in the form of User Stories or can be said to be The Feature List, each task corresponds to the estimated workload using Story Points.
In the middle, you can use color blocks to define the time period of the corresponding task arrangement, and different colors represent different people. Those that are completed regularly become dark, and those that are completed without a corresponding scheduled time become gray.
Mile Stone milestones
milestones should not be explained too much, mainly according to the situation of their own project to define some important time nodes, and then according to the workload and priority of the work in this time period. milestones should include points in time and specific content or criteria defined as "completion".
Product Backlog/Feature List > Sprint Backlog to be completed
We have briefly mentioned the working mode of agile development at the beginning of this article, which divides a long-term large project into several short cycles, each lasting about 1-4 weeks, called a Sprint . At the beginning of the project, according to the Pitch Doc, the team members will transform the goal into a series of features to be developed (features to be implemented) to form the initial Backlog (to be completed tasks).
Early in the development of a project, such as when it is still in the rapid prototype stage, the proposed Backlog may be large and vague because the project requirements are not yet clear. But it doesn't matter, don't think this work is useless at this time, Backlog and Property List will continue to be iteratively updated in the process of continuous clarity of the project, and your estimates will become more and more accurate. As shown in the image below, the Product Backlog typically contains a title name, status, description (written in the form of User Stories), and Size effort estimates.
Then after defining the original Backlog, we can start the Sprint-based development phase. First, according to the overall control and priority judgment of the project in the estimate, the theme of the current Sprint and the criteria and content defined as "completed" are established, and then the parts that meet the Sprint are taken out of the total Backlog, and they are decomposed into specific tasks that are easy to evaluate and supplement the tasks that are not considered, and our Sprint "To Do List" is formed according to the prioritization. The daily station meeting (see below) updates the task version, moving the tasks to be completed today from "To Do" to "In Progress" and the completed tasks to the pending test/confirmation column.Backlogkanban01
Task management kanban, as the main management method of daily progress control, can be done using physical or software such as Trello. However, because such a kanban board is not very conducive to archiving records, the Project Plan mentioned above can assume the role of total control over the archive, take out the corresponding Backlog from the Project Plan, and then update the archive to the Project Plan after the Sprint is completed. Because the team was small and the situation was special, I was the only one who used the project kanban, so in order to facilitate myself, I did not reuse the additional kanban board, but directly used the Project Plan for progress tracking.
After each Sprint, complete a demo version that can be delivered, test it immediately, evaluate this work based on feedback and adjust the next plan. Don't hold back and not test because you are worried that the game is not perfect, and contact the core service subject of the game as soon as possible ,"Player", in order to find problems as soon as possible and adjust the development direction in time. Agile development places great emphasis on playability and requires prioritizing the maintenance of the player experience.
The high demands and frequency of deliverables naturally help us identify and prioritize tasks that improve play ability and user experience, which I think should be the primary consideration in game development.kanban02
User stories
Backlog's description of a need usually needs to be written in the form of User Stories, with the clearest way to make the purpose of the need clear and easy to evaluate. The standard format is as follows:
As a…, I want to…, so that…
as, i want, in order to facilitate.
it should be noted that this "character" refers to the object of this "behavior" service, which is usually the player in the game, but there are other cases such as the development of additional editors for the convenience of development and other service objects that do not belong to the player.
it may seem cumbersome to write in this way, but in fact, the benefits of actually using it are more obvious. first of all, the real development requirements can be more accurately communicated, and the "purpose" can make it clear to the developer why the work is being done, and writing it in this way is equivalent to setting the evaluation body and behavior, providing a measurable standard for post-testing.
Size: Story Points About effort estimates
For workload estimates, Story Points are commonly used in agile development. Story Points are workload comparisons between tasks, regardless of actual productivity (e.g., team size, etc.), and unlike time estimates that we see elsewhere, such as X-person days or Y-hours, which are closely related to specific situations, this method of estimation is more flexible and does not cause all estimates to need to be re-carried out because of changes in specific situations. Everyone's productivity/ability can also be assessed using Story Points. For example, according to the estimate and the actual adjustment, you can basically define the weekly work efficiency of personnel A is 30 points, B is 35 points, etc., and then evaluate the team efficiency accordingly, and arrange how many points of tasks can be put into this Sprint. In actual work, if there is a situation where the actual workload is more or less than estimated, we can judge whether the project may be postponed or completed ahead of schedule based on the statistics of the offset.
When defining Story Points, we can define a task that is considered smallest as 1 and evaluate the remaining Story Points based on the magnitude of the other tasks relative to that task. Planned poker is one of the estimation methods for team participation, the advantage is that it can get a more accurate estimate to the greatest extent, and the disadvantage is that it is more time-consuming.story points
Simply put, everyone has the same pile of poker marked with numbers in their hands, representing the number of points for Story Points. Pick out a Backlog to discuss, and each person privately chooses a workload point card that corresponds to it, and shows it at the same time. If the gap is not large, it can be determined, and if the gap is large, several people with large gaps discuss the reasons for each other, and then continue the game until all members basically agree. This game can help effectively identify tasks that are not well anticipated, and can also enhance communication among team members and resolve potential inconsistencies in understanding of the project.
In addition, the burn down chart and the speedometer are two ways to track the development efficiency, the coordinate parameters are the number of Story Points and time, but one is concerned about the completion speed and the other is how much work is left.Poker
Daily/Weekly Check-in daily stand-in
an important habit in agile development is the daily stand-up meeting, usually at the beginning of the daily/weekly, standing execution to ensure that the reporting is as concise and fast as possible. it is generally required to briefly and directly explain three issues to the rest of the team members:
- Did (after the last meeting): "What did I do last week/yesterday"
- Doing:"What am I going to do today/this week?"
- Blockers: "Did I encounter any obstacles/problems"
These help you to make a clear plan, but also let the rest of the members know your progress, if there is a crossover part of the work can be communicated in time, while invisible pressure will allow you to maintain high efficiency and avoid unnecessary delays.
Version Control version control
in development, version control is extremely important, which is also a necessary project management process in the industry, but as a small white indie developer, you may not realize this in the early days. simply put, version control is to back up the latest problem-free project files to the cloud server at any time, all modifications are made locally, and then update to the server after confirming that there are no problems affecting the normal operation of the project.
Version control greatly promotes the efficiency of multi-person cooperation because it can be developed at the same time, and makes remote cooperation possible, and you can fall back to the previous version at any time if there is a problem. Even if it is an independent development, developing a good habit of using version control will also make the development more organized and controllable. Version control can use a lot of software.
Pipeline workflows
summarizing the workflow diagram (including who is responsible for what parts) and the technical flowchart (including the software used in each part) can help new members integrate into the project as soon as possible, and can also remind team members of the workflow.
however, in the development of small teams, i personally believe that the most important thing should be the resource flow chart (including resource naming rules and storage locations), the earlier the collation, the use of specifications can help the project to maintain orderly and tidy, to avoid the increasingly large project because of the lack of early specifications to sort out, so that the resources are chaotic but unable to start.pipeline3pipeline2
Build Note Update Notes + Bug Report Problem Report + Play test Test
In agile development, it is necessary to develop a good habit of regularly building. (Often exports working versions) and build note, the so-called update notes, are a summary of what is new to that version each time you export, with some update addendums like the ones we usually see in the app store. Build Note's willingness chart is provided to QA for easy testing. However, in small teams, even if we don't have a full-time QA, it's still useful to keep a good habit of writing Build Note, because it helps us sort out what we did in the previous release in time and provide references for testing. In addition, it is important to attach the intention of some necessary changes to the internally used Build Note, because in the long-term development, we sometimes forget why we want to modify a function at that time, and Build Note can help us write down our own design ideas.
In my Build Note, I put the bug report and the test report together, archived it under each version, and then updated it into the Project Plan accordingly. The effective use of Tag to calibrate each entry makes retrieval more convenient, and I test it after each playable version, so each Build Note is followed by a Play test test report, which summarizes some tasks that need to be updated or have a high level of demand according to the test. Similarly, you can use Tag to prioritize task requirements based on test feedback.
Post-Production
Retrospective timely review summary
After each Sprint is completed and completed, don't forget to take a moment to summarize the work or project of the previous period, including what is done well and what is not good, how to improve, and organize the project in time, including source code, final resources and original files, documents, etc. Good retrospective habits can help the team to improve and run, and the well-organized engineering and resources, documentation, etc. also make future updates or secondary development much easier. In short, the future you will thank you for the present.
No comments:
Post a Comment