易于使用的人工智能

by Turgay ?elik

由Turgay?elik

需求分析：如何使用這種易于啟動的方法+一個案例研究 (Requirement Analysis: how to use this startup-friendly approach + a case study)

In our previous blog posts, we explained why we decided to develop the Badges App and how we evaluated the feasibility of our idea at OpsGenie:

在之前的博客文章中，我們解釋了為什么決定開發Badges App以及我們如何在OpsGenie中評估我們的想法的可行性：

Since we found that our idea is worth developing, the next step is analyzing the requirements.

由于我們發現我們的想法值得發展，因此下一步是分析需求。

Requirement analysis — a very well studied area of software engineering — is the process of determining user expectations for a product, or briefly defining the product scope. There are tons of available resources on requirements analysis methodologies, characteristics of good requirements and tracing requirements. Instead of repeating the literature, we are going to summarize the critical points in a startup thinking way.

需求分析是一個非常深入的軟件工程領域，是確定用戶對產品的期望或簡要定義產品范圍的過程。關于需求分析方法，良好需求的特征和跟蹤需求，有大量可用資源。與其重復文獻，不如以一種新的思維方式來總結關鍵點。

We know, startup guys generally don’t like terms like “process”, “proof of concept”, “requirements”, “scope”, “schedule”, “design”, “documentation” or “maintainability”. Generally they are impatient and they just want to code and release. We accept that agility is vital in our world and we have to try, fail and recover fast. But benefiting from the heritage of the software world will help us on the way to success. The key point is keeping it agile.

我們知道，剛開始的家伙通常不喜歡“過程”，“概念證明”，“需求”，“范圍”，“計劃”，“設計”，“文檔”或“可維護性”之類的術語。通常，他們不耐煩，只想編碼和發布。我們接受敏捷性對我們的世界至關重要，我們必須嘗試，失敗和快速恢復。但是受益于軟件世界的遺產將幫助我們邁向成功之路。關鍵是保持敏捷。

Following a process is not an objective, it is a tool that helps us achieve our goals. So, let’s see how we can adopt classical approaches to our world in the context of requirements management.

遵循流程不是目標，而是幫助我們實現目標的工具。因此，讓我們看看如何在需求管理的背景下對我們的世界采用經典方法。

The Project Management Triangle is a model of the constraints of software management. Despite the fact that it is an old concept from the 1950's, I think it is still relevant.

項目管理三角形是軟件管理約束的模型。盡管它是1950年代的舊概念，但我認為它仍然有意義。

In summary, project management triangle says that the quality of work is constrained by the project’s budget, deadlines and features. There is a trade-off among these three constraints to achieve the necessary project quality. So we can say that software development is a multi-objective optimization problem.

總而言之，項目管理三角表示工作質量受到項目預算，期限和功能的限制 。為了獲得必要的項目質量，需要在這三個約束之間進行權衡。因此可以說軟件開發是一個多目標優化問題。

We don’t like to constrain ourselves by classical approaches, so let’s adapt the old Project Management Triangle to the new startup world. Recall the Startup Success Factors that we mentioned at Feasibility Analysis post.

我們不喜歡用經典的方法來約束自己，所以讓我們將舊的項目管理三角形適應新的創業世界。回想一下我們在可行性分析后提到的啟動成功因素。

Here is how we map these success factors to the classical project management triangle:

這是我們將這些成功因素映射到經典項目管理三角的方法：

As shown in the table above, all startup success factors relate to various project management triangle constraints. Since these three constraints are in a trade-off, we can say that keeping the scope neat is vital for the success of a startup.

如上表所示，所有啟動成功因素都與各種項目管理三角約束有關。由于這三個約束是折衷的，所以可以說保持范圍整潔對于啟動成功至關重要。

To define a neat scope, we have to perform a good requirement analysis before starting the development. Please note that this does not mean we are going to perform a fully detailed requirement analysis just like defined in waterfall process. We are going to do it in agile way.

為了定義一個整潔的范圍，我們必須在開始開發之前進行良好的需求分析。請注意，這并不意味著我們將像瀑布過程中定義的那樣執行全面詳細的需求分析。我們將以敏捷的方式做到這一點。

需求分析技巧 (Tips for Requirement Analysis)

In this section, we will provide important tips that you should keep in mind:

在本節中，我們將提供您應該記住的重要提示：

深入檢查替代/同類產品 (Inspect Alternative/Similar Products In Depth)

As always, don’t reinvent the wheel. Check what others do to meet your objectives. Even you may end up realizing that your product does not seem to have business impact that you were thinking before.

與往常一樣，不要重新發明輪子。檢查其他人為實現您的目標所做的事情。甚至您可能最終也意識到，您的產品似乎并沒有像您以前想的那樣對業務產生影響。

This is a good sign to pivot your idea. It may seem like a failure, but remember, we have to fail as fast as possible.

這是改變您的想法的好兆頭。這似乎是一個失敗，但請記住， 我們必須盡快失敗 。

記錄您的要求 (Document your requirements)

You don’t have to use a requirements management tool such as IBM Rational DOORS. But a short, bulleted requirements document will help negotiate with the stakeholders.

您不必使用諸如IBM Rational DOORS之類的需求管理工具。但是，簡短的項目符號需求文檔將有助于與利益相關者進行談判。

讓您的(潛在)客戶保持聯系 (Keep Your (Potential) Customers In the Loop)

I think this is one of the most important things about requirements development. A capability that you think that is killer may not make sense to the customers.

我認為這是需求開發中最重要的事情之一。您認為致命的功能對客戶而言可能沒有意義。

To keep your potential customers in the loop, you have to follow an iterative approach. You can do this by shipping an initial version of your product — Minimum Viable Product (MVP) — and evolving it according to customer feedback.

為了使您的潛在客戶保持聯系，您必須采用迭代方法。為此，您可以交付產品的初始版本-最低可行產品(MVP)-并根據客戶反饋對其進行改進。

For example, Amazon Web Services team utilizes this approach frequently. They ship a service with minimum capabilities and evolve it based on customer feedback.

例如，Amazon Web Services團隊經常使用此方法。他們以最低的功能交付服務，并根據客戶的反饋進行發展。

Another approach is to develop mock applications that just provide a dummy user interface (UI) to help potential customer to understand the product features and give feedback. You can use products like InvisionApp to produce these mocks.

另一種方法是開發僅提供虛擬用戶界面(UI)的模擬應用程序，以幫助潛在客戶了解產品功能并提供反饋。您可以使用InvisionApp之類的產品來生成這些模擬。

需求管理是一個連續的過程 (Requirements Management is a Continuous Process)

You don’t have to spend months for requirements analysis at the beginning of a project, and please don’t — it is not the agile way.

在項目開始時，您不必花費數月的時間進行需求分析，請不要這樣做-這不是敏捷方法。

At the beginning, your objective is to define boundaries of the system, negotiate with the team and other stakeholders, and prepare the definition of the Minimum Viable Product. The requirements should be detailed or can even evolve during iterations of development.

首先，您的目標是定義系統的邊界，與團隊和其他利益相關者進行談判并準備最小可行產品的定義。需求應該是詳盡的，甚至可以在開發的迭代過程中不斷發展。

分組您的要求 (Group your requirements)

After you create a list all of your requirements, group them (divide and conquer) to form sets of related features. Grouping requirements to feature groups will ease your life during development phase and even it can help you to define bounded contexts, microservice architectures, and so on.

創建所有需求列表之后，將它們分組(分而治之)以形成一組相關功能。將需求分組到功能組將簡化您在開發階段的工作，甚至可以幫助您定義有限的上下文，微服務體系結構等。

考慮UX (Think About UX)

It is not necessary to say that User Experience (UX) is a very important factor in the success of a product anymore; today it is so obvious. But we have to still remind that User Experience is not just about fancy User Interfaces.

不必說用戶體驗(UX)成為產品成功的一個非常重要的因素；今天是如此明顯。但是，我們仍然必須提醒用戶體驗不僅僅是花哨的用戶界面。

As the name implies, it is all about the “experience” and it is hard to improve a system’s UX after it is developed.

顧名思義，這一切都與“體驗”有關，開發系統后很難改進其用戶體驗。

Think about UX starting from requirements analysis, it could even be a motivation during the feasibility analysis phase to develop a new product if available alternatives in the market lack good UX.

從需求分析開始考慮用戶體驗，如果市場上的可用替代品缺乏好的用戶體驗，那么甚至可能是在可行性分析階段開發新產品的動機。

User Experience affects the business requirements. For example, if you are developing an e-commerce application, designing a fast responding customer support system is about improving the User Experience.

用戶體驗會影響業務需求。例如，如果您正在開發電子商務應用程序，那么設計一個快速響應的客戶支持系統就是要改善用戶體驗。

盡可能不了解實施技術 (Be Agnostic of Implementation Technologies As Much As Possible)

Of course this is not applicable if you are developing an infrastructure or a library for a specific technology :)

當然，如果您正在為特定技術開發基礎結構或庫，則此方法不適用：)

Don’t fall into “If all you have is a hammer, everything looks like a nail” trap. Find new tools and utilities instead of limiting product capabilities to the technologies that you are familiar with or that you enjoy playing with.

不要陷入“如果只有錘子，一切看起來都像釘子”陷阱。查找新的工具和實用程序，而不是將產品功能限制為您熟悉或喜歡使用的技術。

In enterprise companies, requirements analysis is generally performed by non-software engineers who are generally known as business analysts or systems engineers. This separation has some disadvantages, especially in terms of transferring requirements to development teams, but I think it also has some advantages.

在企業公司中，需求分析通常由通常稱為業務分析師或系統工程師的非軟件工程師執行。這種分離有一些缺點，特別是在將需求轉移到開發團隊方面，但我認為它也有一些優點。

In my opinion, the biggest advantage of independent analysis teams is that they are agnostic of the technologies that will be used during development.

在我看來，獨立分析團隊的最大優勢是他們對將在開發過程中使用的技術不可知。

But in the startup world, most probably as a team member (or even as a founder), you have to wear multiple hats: analyst, developer, hiring manager, or even more interesting roles that you were not imagining when you get in this path. So, if you are wearing the analyst hat at the moment, try to be agnostic of the technologies that you are planning to use during implementation.

但是在創業世界中，很可能作為團隊成員(甚至是創始人)，您必須戴上多個帽子：分析師，開發人員，招聘經理，或者甚至更有趣的角色，而當您走上這條路時。因此，如果您現在戴著分析員的帽子，請不要理會計劃在實施過程中使用的技術。

We consistently hear expressions like “but Spring Framework does not support …” and “This causes a lot of work on the front-end” during requirement analysis.

在需求分析過程中，我們始終聽到諸如“但Spring Framework不支持…”和“這在前端導致大量工作”之類的表達。

Considering these kind of limitations at the start degrades the quality of the end product. Let’s define the ultimate capability and evolve it during development if necessary.

一開始考慮這些限制會降低最終產品的質量。讓我們定義最終功能，并在必要時在開發過程中對其進行發展。

Ultimate capability is the final goal to reach, you can implement a more simple form of it when you start and evolve it in future versions. But knowing the point that we want to reach will help us to define our vision for the growth of the product.

最終功能是最終的目標，您可以在開始并在將來的版本中進行擴展時，以更簡單的形式實現它。但是，知道我們要達到的目標將有助于我們確定產品增長的愿景。

For example, think about “pinch-to-zoom” capability of mobile phones. It seems like a trivial capability but it was a revolution when Steve Jobs first demonstrated it. If the designers of iPhone didn’t think out-of-the-box and stuck to the available technologies and methods, we would not have this great functionality today. We know that it is an exaggerated example, but the main point is, don’t let the technology you would like to use limit you, you can move to other technologies if this will help you to create a niche product.

例如，考慮一下手機的“縮小縮放”功能。這看似微不足道的功能，但這是史蒂夫·喬布斯(Steve Jobs)首次展示它時的一次革命。如果iPhone的設計師沒有開箱即用的想法，而是堅持使用可用的技術和方法，那么今天我們就不會擁有如此強大的功能。我們知道這是一個夸張的示例，但要點是，不要讓您想使用的技術限制您，可以使用其他技術來幫助您創建利基產品。

徽章應用程序的需求分析 (Requirements Analysis for Badges App)

We performed requirements analysis according to the practices that we summarized above:

我們根據上面總結的實踐進行了需求分析：

We defined an initial set of requirements
我們定義了一組初始要求
We shared the requirements with our initial customer — The OpsGenie team — and updated the requirements according to the team’s comments.
我們與最初的客戶OpsGenie團隊共享了需求，并根據團隊的評論更新了需求。
At OpsGenie, we use Atlassian’s JIRA for issue tracking. To track the requirements, we created an issue with “New Feature” type for each requirement in JIRA.
在OpsGenie，我們使用Atlassian的JIRA進行問題跟蹤。為了跟蹤需求，我們為JIRA中的每個需求創建了一個“新功能”類型的問題。
We grouped related requirements with JIRA Epics. Some of our epics are User Operations, Group Operations, Badge Operations, Endorsement and 3rd Party Tool Integration.
我們將相關需求與JIRA Epics進行了分組。我們的一些史詩是用戶操作，組操作，徽章操作，背書和第三方工具集成。
In further steps of development, we created detailed issues for daily tasks, as Agile practices recommend. We linked each task with one or more requirements to keep traceability of development activities with requirements.
在進一步的開發步驟中，我們按照敏捷實踐的建議為日常任務創建了詳細的問題。我們將每個任務與一個或多個需求相關聯，以保持開發活動與需求的可追溯性。
Each epic contains a set of requirements (such as a New Feature), Development Tasks, and Bugs.
每個史詩都包含一組要求(例如新功能)，開發任務和錯誤。

Want to follow our Badges app, or better, recommend new features and help us refine it? Join Badges App community!

想要關注我們的徽章應用，或者更好地推薦新功能并幫助我們完善它？加入徽章應用社區！