開發者談如何以實際行動構建高質量遊戲

本文原作者:Johan Hoberg 譯者ciel chen

在該文章中我將對我所認爲作爲構建高質量遊戲以及一般軟件所應具備的良好基礎進行探索。我會講到很多不同的主題,這些主題的共同點是——我相信它們都爲構建高質量遊戲的目標做出了貢獻。我不會細講每一個主題,但是適當的時候我會提供補充閱讀材料。這不會是一個詳盡的清單列表,肯定還有其他一些重要的因素我沒有覆蓋到,但是從我的角度看來我所提到的那些都是最關鍵的部分,所以爲了重申其重要性我要把這些字眼粗體讓它們更清晰:

“我相信下面的內容都是構建高質量遊戲的關鍵基石。”

理解什麼是質量

爲了構建高質量遊戲我們首先不得不先要有對“高質量”的一個確切概念。我認爲Gerald Weinberg說得最好了:

“質量就是對一些人來說存在的價值。”

IndieDevDiary1-GameDevelopment(from gamasutra)

IndieDevDiary1-GameDevelopment(from gamasutra)

如果你要向你的顧客推薦一款遊戲,那麼這款遊戲就應該具備高質量。一款沒事就崩潰的軟件通常對用戶是沒有什麼高質量可言的,所以我們可以認爲這種軟件是低質量產品。我們要懂得從對人類價值的方面來考慮產品——只要產品價值高,漏洞多、或者任何其他的指標什麼的都沒多大關係,反之則相反。一款沒有任何漏洞的產品,也可能質量低到無法提供人們以任何價值。

理解什麼是複雜性

我們在構建的是複雜性產品,而複雜性問題被定義爲:需要根據追溯回憶推理而得出因果關係的問題,所以這裏的含義是非常廣泛的。一項共產黨管理國家的五年計劃,這種複雜性可以說是沒什麼意義的,因爲這裏的複雜程度讓你根本不知道怎麼解決這個問題,而這對於一份詳盡的研究與開發項目計劃來說也是如此。研究與開發是複雜的,任何想要對這些項目進行預先規劃的努力都是徒勞的——你只有先觀察,然後做出調整去適應:工作開始時,先觀察工作成果,然後調整適應新形勢。如果你所創的規劃概述了一個開發項目的範圍,然後你設定了項目完成的日期,這時爲了彌補形勢改變,你唯一可以修改的變量因素就是質量。

信任與授權

永遠也別對複雜的事物進行微觀化管理。複雜問題的處理不僅要求對問題能深度瞭解,而且要有應變能力。一名管理者如果跟每天的工作脫節,那他既無法瞭解工作內容,也無法做出解決複雜問題的正確決策。管理需要建立應有的信任,然後讓專家來解決問題,而這就需要授權讓他們去做出調整來應對隨時變化的情勢。如果你想要構建一個高質量複雜性產品,你就要說明你需要解決的問題,而不是告訴專家怎麼解決這些問題,因爲沒有人能提前知道問題是什麼樣的。

所有權

但是爲了建立信任,開發團隊要擁有產品的所有權。也就是說你所爲之工作的產品,其價值歸你所有。因此你也就有責任要交付其價值,你需要擔負起產品的所有責任。無論你的角色作用是什麼,或者你有什麼樣的能力——只要你看到什麼是有損產品價值的,那你就有責任去處理它。

多功能且真誠的團隊

爲了創建這種基於信任的所有權文化,你可能需要成立一支相對久遠、多功能型、真誠的團隊。對於一支有能力擁有問題或產品的團隊來說,他們得要有所需的完整技能組來解決這些問題或開發這件產品。一旦你開始在團隊之間劃分工作,並且在團隊之間有太多的依賴關係,你就會破壞產品所有權並造成瓶頸。因爲這會讓成員有一種事情出錯不是自己的問題,是別的團隊成員的問題,造成團隊成員之間責任的推卸。所以你還要建立一支高效的團隊,他們要能夠交付高價值產品,當然這需要時間。如果你經常性地在團隊之間把人員像資源一樣調動,這樣很難建設一種基於信任的產品所有權文化,並且團隊將很難發揮出他們真正的潛能。

Monument Valley(from gamesindustry.biz)

Monument Valley(from gamesindustry.biz)

信息多樣化

信息多樣性在團隊中是很重要的,比如說,你會需要不同的產品背景、整套技能組、豐富經驗以及對問題的看法。調查發現,信息多樣化可以激發大家對手頭上的任務的建設性衝突與辯論。也就是說,人們進行的是對最佳化行動的思考——這就是解決複雜性問題和提高高價值產品的關鍵。

重視團隊能力,忘記自己的角色

當你湊齊了一支多功能型的隊伍時,你要思考的是解決複雜問題需要哪些能力,而不是你要扮演什麼樣的角色。你扮演的角色並不重要,解決問題纔是重點。團隊的每個人都應該儘自己所能地去解決問題。無論是誰,只要有能力就應該去做爲了達到目標必要做的事,而不應該工作角色描述裏的人爲概念所侷限。有一些任務也許需要編程專家來完成,然而有一些則只需要基本的編程技巧就好。第二種任務就可以由那些平常不怎麼寫代碼的人來完成。總之就是說如果你有解決問題的能力,你就應該去解決這些問題。所以說團隊的每一個成員都是產品的一個開發者,有些編程很厲害,而有些則在產品測試、美工、UI、UX、設計等方面很厲害——但每個人都應該努力去讓自己具備各個領域的基本技能。

反饋和社會契約

爲了能有一個功能性較高的團隊,那不僅需要股東們適當的產品反饋,還需要在團隊內部的反饋演示。股東們應該要參與到生產的過程中來,這是非常有價值的一件事,還有團隊需要能持續地重新審視他們的工作原理以及對形勢變化的應變方式。

所以需要簽訂一份社會契約。每個成員都需要知道所有的反饋都是爲了以可能性最大的方式去開發出最有價值產品。要去幫助人們成長和發展,而不要去評判表現、批評或袒護權利。

合理的測試外包

總有某些能力或者設備是團隊沒能具備的。比如本地化測試就是個很好的例子。測試會很繁瑣,昂貴的設備也是另一個因素。不同類型的認證測試會需要外部方的加入。總的來說你需要找到方法讓測試儘可能地在團隊內而完成,並能夠對何時應該將測試外包給公司其他部門或者第三方做出明智的決策。

爲什麼不把所有的測試都外包給別人,讓團隊專注於開發呢?這裏有很多原因,但是最重要的是這個:所有權(歸屬感)。團隊存在問題,就要解決問題,如果你把所有的測試都外包了從某種意義上來說你不經意地把這個產品的所有權也轉移了。

但是還有非常多的原因:反饋循環和交流問題;以詳盡的程序測試、不必要的漏洞報告以及額外的需求規格說明所這些形式所產生的浪費;更長的週轉時間等等。

探索性測試

在大多數情況下,製造手動程序測試並反覆地運行它們是一種浪費——所以別做這種測試。你要始終假設你的產品開發人員門是具備高等級測試能力的,他們將進行探索性的測試(你需要學習並理解這種概念),然後當你看到了創建的程序測試存在切實價值時,就做這種測試就好了。不過也要考慮下在這些情況下編寫一些自動化測試——如果你要爲了什麼目的創建一個人工程序測試,那麼創建一個自動化測試幾乎總是更好的。

風險性測試

你永遠不可能有時間把所有的測試都運行一遍。你需要分清輕重緩急。你輸入的這個優先順序選擇會有所不同,不過一旦定下來,你會知道要測試什麼才能讓你的測試活動價值最大化。在某種程度上,你會有足夠的信息來進行產品質量風險評估,然後你把這些信息提供給團隊成員和股東們。如果有人想要進一步降低風險,你就繼續你的測試活動,如果他們不再有這樣的需要,你就可以停止測試。

運行所有可能的測試不僅不可能,因爲幾乎每個複雜的產品都有無數的測試,而且即使有可能,這也是一個資源浪費的巨坑,這些資源本可以用來更好地生產價值的。
另外,不要認爲預定義的程序測試涵蓋了所有可能的測試,並不是的。

運營與開發之間的協作

一旦說遊戲上線,不幸地告訴你,產品仍然歸你所有。所以要確保開發團隊和運營上線產品的有關人員要保持密切的協作關係——比如說在客戶支持工作,再比如說IT運營工作。如果你有數據科學部門來研究傳入的數據,那麼他們也同樣很重要。

服務型的領導力

管理人員應該明白,他們在戰場上的將軍角色正在消逝。指導、賦能、支持纔是一個管理人員現在的工作內容。如今爲了高效地開發出高質量軟件,我們需要的正是這樣一支技藝精湛的、有幹勁的、自主性地匯聚在一起的這樣一隻真誠的團隊。他們最不需要的就是有人站在他們的肩膀上試圖對他們進行微觀管理。

如果你鉅額被上述列出的要素,你就可以開發出高質量的遊戲或者任何其他高質量軟件。這並不是通過其他方面達不到這樣的效果,但是肯定沒這些來的有效。開發高質量遊戲跟生產易拉罐蘇打水是不可同日而語的——上個世紀所定義的最佳實踐不再是運營軟件開發組織的最佳方式。每個人都要去適應——要不就得被替換。

本文由遊戲邦編譯,轉載請註明來源,或諮詢微信zhengjintiao

In this article I will explore what I believe is a good foundation for building high quality games, and software in general. I will cover a wide array of different topics which have in common that I believe they all contribute to this goal. I will not go into detail on every topic, but will try to provide additional reading material when appropriate. This is not an exhaustive list and there are of course other important factors that I will not cover, but I have added those that are most crucial from my perspective. So to iterate and and be bold and clear:

“I believe that the following components are crucial building blocks which enable the creation of high quality games”

Understanding Quality

To build high quality games we first have to have an idea of what that actually means. I believe that Gerald Weinberg said it best:

“Quality is value to some person.”

If you deliver a game that is of high value to your customers, then that game has high quality. A software that continuously crashes usually does not provide its users with high value, thus we could consider it as a low quality product. Always think in terms of value to people. Number of bugs, or any other metric does not matter if the value is high, and the other way around. You can have zero bugs and still have a low quality product that does not provide value to anyone.

Understanding Complexity

We are building complex products, and complex problems are defined as problems where cause and effect can only be deduced in retrospect. The implications of this are huge. A communist five year plan for governing something as complex as a country is pointless, since you can never know in advance how to solve this complexity. The same goes for detailed project plans for research and development. Research and development is complex, and any attempts to plan these projects in detail up front is a fool’s errand. You have to inspect and adapt. Start working, inspect the outcome of that work, and adapt to the new circumstances. If you create a plan that outlines the scope of a development project, and you set a date for when you want this project to be complete, the only factor you can modify to compensate for changing circumstances is quality.

Trust & Mandate

You can never micromanage your way through complexity. Not only does solving complex problems require a high level of understanding, it also requires the ability to adapt. A manager disconnected from the everyday work does not have the understanding, and cannot make the right decisions for solving these complex problems. Trust needs to be established between management, and the experts solving the problems, and this needs to come with a mandate to adapt to changing circumstances. If you want to build a high quality complex product, you can state what problems you want solved, but not how the experts are going to solve them, because this is not known in advance.

Ownership

But for trust to be established ownership must be taken by the development teams. When you work on a product you own the value of that product. You are responsible for delivering value, and that includes everything. It does not matter what your role is, or what competence you have – if you see something that detracts from value, then it is your responsibility to make sure it gets addressed.

Cross-functional, Genuine Teams

To create this trust-ownership culture you need to build relatively permanent, cross-functional, genuine teams. For a team to be able to own the problem or product they are working on, they need to have the entire skillset required to solve that problem or develop that product. As soon as you begin dividing work between teams and have too many dependencies between teams, you are eroding ownership and creating bottlenecks. It is never your fault something is wrong, it is some other team’s problem. When you see a value detractor you assume another team will pick it up.

You also need to build effective teams that are able to deliver high value and that takes time. If you continuously move people between teams like resources in an excel sheet you will never be able to build a trust-ownership culture, and the teams will never reach their true potential.

Informational Diversity

Informational diversity is important in a team, i.e. you need different background, skillsets, experiences and views of problems. Research has found that informational diversity stirs constructive conflict, or debate, around the task at hand. That is, people deliberate about the best course of action. This is key to solving complex problems and providing high value.

Competence, Not Roles

When you are putting together your cross-functional team you need to think about the competences needed to solve the complex problems, not which roles you are suppose to have. Roles are not important, solving the problem is. Everyone in the team should do whatever it takes to solve the problem. Whomever is capable should do what is necessary to reach the goal, and not be limited by artificial constructs such as role descriptions. Some tasks might require an expert programmer, while some require rudimentary programming skills. The second of these tasks could potentially be picked up by someone who does not normally write code. If you have the skills to solve the problem, then you solve the problem. So everyone in the team is a product developer, and some have high competence in programming, while others have high competence in testing, art, UI, UX, design, etc. But everyone should strive after having some rudimentary competence in all areas.

Feedback & Social Contracts

To be able to have a high functioning team, not only does it require proper product feedback from stakeholders, but also performance feedback within the team. Stakeholders need to be involved in what is being produced, and that it is of high value, and the team needs to continuously revisit how they work and adapt to changing circumstances.

There needs to be a social contract in place. Everyone needs to know that all feedback is giving with the intent of developing the most valuable product in the best possible way. To help people grow and develop, not to evaluate performance, criticize or assert power.

Motivation

We need highly motivated people to solve complex problems. Modern motivational theory promotes intrinsic motivation which can be nurtured in a number of way:

What we do not want is the more traditional extrinsic motivation in the form of carrots and sticks, rewards and threats. To solve complex problems efficiently motivation needs to come from inside. In short, for this to happen, people need to be surrounded by people they can relate to, they need to feel that they are growing, that they are not micro-managed, and that what they are doing makes a difference.

Quality Intelligence, Not Quality Assurance

You can never test quality into a product. Testing will never assure quality. What it will do is give you information about the state of the product. You can then use that information in any number of ways. So get rid of the old QA acronym, and the old way of thinking about QA and testers as gatekeepers of quality, and instead adopt Quality Intelligence:

“Quality Intelligence is a set of techniques and tools for the acquisition and transformation of raw data into meaningful and useful information for quality analysis purposes”

Quality is owned by the development teams, and testers are part of those teams, but everyone in the team should feel equal ownership of the quality of the product.

Design for Testability

Testing is not an activity you tack on at the end of your development process, performed by someone outside of the development team. Testing should be part of the development process from the start. During planning, during design, during development, you should always think about testing and quality. Testing is a continuous activity throughout the development cycle, involving everyone in the development team.

Designing your code for testability will much improve your chances of implementing a successful automated test framework and automated tests, but also help make the manual testing more valuable, with for example opportunities to support this with different tools.

Everyone Tests to their Ability

Testing is not an activity exclusively performed by testers. Complex testing problems are solved by testers. Obvious problems can be solved by anyone, and that goes for all fields of product development. Obvious programming problems can be solved by anyone with rudimentary programming skills, and obvious testing problems can be solved by anyone with rudimentary testing skills. And everyone has rudimentary testing skills.

Developers test their own code to the best of their ability, and if the code is complex, then most likely someone with a higher level of test competence supports the developers with additional testing.

And everyone in the team helps regression test the game before a release. The Product Owner, the Scrum Master, the programmers, the artists, the game designers, the data scientists. Everyone.

Outsource Testing Right

There will always be certain competences or equipment that are not feasible to have within a development team. Localization testing could be one example. Testing which requires cumbersome, expensive equipment could be another. Different sorts of certification testing might require an external party. In general you should always look for ways to keep as much of the testing within the team as possible, and make informed decisions on when to outsource testing to other parts of the company or third parties.

Why not outsource all testing and focus on development within the team? There are many reasons for this, but the absolute most important one is: Ownership. The team owns the problem, and the team should solve the problem. If you outsource testing you are most likely also inadvertently transferring some of that ownership as well.

But then there are tons of other reasons: Feedback loops and communication problems. Producing waste in forms of detailed test cases, unnecessary bug reports and additional requirement specifications. Longer turnaround times. And so on.

Exploratory Testing

In almost every case, producing manual test cases and running them over and over again is a waste. Don’t do it. Always assume you product developers with a high level of test competence will perform exploratory testing (you need to learn and understand this concept), and then in the cases where you see an actual value in creating a test case, do it. But also consider writing automated tests in these cases – if you need to create a manual test case for something, then it is almost always better to create an automated test instead.

This is the only way you will be able to handle all the testing required inside you development team.

Risk-based Testing

You will never have time to run all possible tests. You need to prioritize. What input you choose for this prioritization will differ, but once it is done, you will know what to test to get the most value out of your test activity. At some point you will have enough information to make a product quality risk assessment, and then you provide this information to the team and stakeholders. If someone wants to reduce risk even more, you continue your test activity, and if they do not, then testing stops.

Running all possible tests every test activity is not only impossible, since there is an almost infinite amount of tests for every complex product, but even if it was possible it is a giant waste of resources, that could be better spent producing value.

Also stop thinking that your predefined test cases cover all possible tests. They do not.

Continuous Integration

This is common knowledge by now, but when you work in a team, sitting in isolation working on your own code for a long time, and then trying to integrate it to the master branch is not a good idea. Integrate often, and have an automated test framework that enables fast feedback. Also make sure that you have someone with test competence continuously looking at the master branch, analyzing risk and performing more complex tests when needed. And never merge anything to the master branch without testing to the extent of your abilities first.

Collaboration between Operations and Development

Once a game goes live, unfortunately your ownership of the product does not go away. Make sure to have a close cooperation between the development team and those involved in operations of the live product. Customer Support is one example, IT operations is another. If you have a data science department looking at incoming numbers, then they are also important.

Servant Leadership

Managers should understand that their role as generals on a battlefield is going away. Coaching, enabling and supporting is what a manager should be doing. Highly skilled, driven individuals, grouped together in self-organizing, genuine teams working on complex problems is what is needed today to develop high quality software efficiently. The last thing they need is someone looking over their shoulder, trying to micromanage.

If you have the above listed building blocks covered, you are in a good place to be able to develop high quality games, or any other piece of software. That is not to say that it is impossible to do otherwise, but it is definitely less efficient. Developing high quality games is not the same thing as manufacturing soda cans – what was defined as best practices last century is no longer the best way to run your software development organization. Everyone will need to adapt, or be replaced.(source:gamasutra.com