件開發是許多企業討論的熱門話題。因此，圍繞它往往會有很多炒作，因此，誤解比比皆是。以下是我們遇到的關於敏捷軟件開發的5種常見誤解。

誤解一：敏捷對人的要求很高

很多人在嘗試實施敏捷時說：敏捷對人的要求太高了，我們沒有這樣的條件，我們沒有這樣的人，因此我們沒法敏捷。可是，敏捷對人的要求真的那麼高麼？軟件歸根到底還是一種創造性活動，開發人員的技術水平和個人能力對軟件的質量還是起著決定性的作用，各種過程與方法只是幫助開發人員、測試人員等角色能夠更好的合作，從而產生更高的生產力。不管用什麼方法，開發人員的水平永遠都是一個主要的因素。

從另一個角度來看：過程和方法究竟能幫開發人員多大忙？對於技術水平較低的開發人員，敏捷方法和傳統方法對他的幫助是差不多的，因此看不到顯著的效果，甚至有些時候還有反效果；而隨著開發人員技術水平的提高，敏捷方法能夠解開對人的束縛，鼓勵創新，效果也會越來越顯著。

敏捷對人的要求並不高，而且會幫助你培養各種所需的能力，當然前提是你處在真正敏捷的環境中。

誤解二：敏捷沒有文檔，也不做設計

這個誤解從XP開始就沒有停止過，XP鼓勵“在非到必要且意義重大時不寫文檔”。這裡面提到的“必要且意義重大”是一個判斷標準，並不是所有的文檔都不寫。例如，用戶手冊是不是“必要且意義重大”？這取決於客戶的要求，如果客戶不需要，那就不用寫,如果客戶需要，就一定要寫；再如，架構設計文檔要不要寫？複雜要寫，不復雜不用寫。通常架構設計只需要比較簡單的文檔，對於有些項目，一幅簡單的UML圖就夠了。因此，寫不寫，怎麼寫，都要根據這個文檔到底有多大意義，產出和投入的比例，以及項目的具體情況決定。實際操作時可以讓項目組所有人員表決決定，盡量避免由某一個人（比如lead）來決定。

至於設計，XP奉行的是持續設計，並不是不設計。這實際上是將設計工作分攤到了每天的日常工作中，不斷的設計、改善（重構），使得設計一直保持靈活可靠。至於編碼前的預先設計，Kent Beck等人確實實行著不做任何預先設計的開發方式，但是對於我們這些“非大師”級開發人員，必要的預先設計還是需要的，只是不要太多，不要太細，要有將來會徹底顛覆的準備。

誤解三：敏捷好，其他方法不好

有些人一提到敏捷就大呼好，只要是敏捷的實踐就什麼都好，而提到CMMI等方法就大呼不好，不管是什麼只要沾上邊就哪裡都不好，似乎敏捷和其他方法是完全對立的。牛頓說過，我是站在了巨人的肩膀上。敏捷同樣也吸取了其他方法論的優點，也是站在了巨人的肩膀上，敏捷依然保持了很多歷史悠久的實踐和原則，只是表現方式不同罷了。

從另一個方面來看，方法本沒有好環，好與壞取決於是否適合解決你的問題。每一種方法都有他最善於解決的問題和最佳的發揮環境，在需求穩定、軟件複雜度相對不高的時代，瀑布模型也可以工作的很好，而敏捷恰好適用於變化快風險高的項目－這恰恰是現在很多項目的共性。

因此選擇一個方法或過程，並不是根據它是否敏捷，而應根據它是否適合。而要了解一個東西是否適合，還是要嘗試之後才知道，任何沒有經過實踐檢驗的東西都不可信。

誤解四：敏捷就是XP（極限編程），就是Scrum

XP 和Scrum只是眾多敏捷方法中的兩種，還有很多其他的敏捷方法。龍生九子各個不同，敏捷的這些方法看起來差別也是很大的，可是他們之所以被稱為敏捷方法，就是因為他們背後的理念和原則都是相同的，這個原則就是《敏捷宣言》。學習敏捷不僅僅要學習實踐，還要理解實踐後的原則，不僅要理解怎麼做，還要理解為什麼這麼做，以及什麼時候不要這麼做。

即使將XP或Scrum完全的應用的你的項目中，也未見得就能成功，適合別人的東西未必就適合你。敏捷的這些實踐和方法給了我們一個起點，但絕對不是終點，最適合你的方式還要由你自己在實際工作中探索和尋找。

誤解五：敏捷很好，因此我要製定標準，所有項目都要遵循著個標準

沒有哪兩個項目是一樣的，客戶是不一樣的，人員是不一樣的，需求是不一樣的，甚至沒有什麼可能是一樣的。不一樣的環境和問題，用同樣的方法解決，是不可能解決的好的。方法是為人服務的，應該為項目團隊找到最適合他們的方法，而不是先確定方法，再讓團隊適應這個方法。因此也不存在適合所有項目的統一的方法。任何企圖統一所有項目過程的方法都是不正確的。

同時，對於同一個團隊，隨著項目的進行，對需求理解的深入，對技術理解的深入，一開始適合項目的過程和方法也會漸漸的不適合。這時候也需要團隊對過程進行及時的調整，保證項目的質量和效率。敏捷是動態的，而非靜止不變的，因為這個世界本身就是變化的，在變化的世界使用不變的方法，是不現實的。銀彈從來就沒有過，在有限的將來也不會存在。

如何使用Scrum Board进行敏捷开发？

Scrum boards (also known as scrum task boards) are tools that help teams visualize backlogs of sprint work items. The board can use many manual (whiteboard and sticker) and virtual forms (software tools), but it can perform the same function regardless of appearance. (Scrum 板 (也称为 scrum 任务板) 是一种工具, 可帮助团队使冲刺积压工作项可见。该板可以采用许多手动 (即白板和贴纸) 和虚拟表单 (即软件工具), 但无论外观如何, 它都能执行相同的功能。)

如何为Scrum项目撰写产品愿景？模板和示例

The product vision is not part of the Scrum process. Why is it so important? Schwaber believes that vision is two necessary illusions, starting the Scrum project by stating: "The smallest plan starts the vision of the necessary Scrum project composition and product backlog" (产品愿景不是Scrum流程的一部分，为什么它如此重要？Schwaber的认为，愿景是两个必需的一个假象，开始Scrum项目，通过陈述道：“ 最小的计划开始了必要的Scrum项目组成的愿景和产品Backlog ”)

Scrum: 什么是产品Backlog中的DEEP？

Product Backlog projects have described attributes (D appropriate details), Story points (E stimated), order (P rioritized), and they are constantly added, deleted and updated (E merged) in the backlog to reflect the backlog of teams in a timely and appropriate manner. (产品Backlog项目具有描述的属性（D适当的详细说明），Story points（E stimated），order（P rioritized），并且它们在积压中不断被添加，删除和更新（E合并）以反映到对以及时和恰当的方式积压团队的积压。)

如何为用户故事撰写SMART和INVEST目标?

SMART is a set of standards for creating goals such as Sprint goals. While INVEST reminds you of the characteristics of high-quality product backlog (PBI) (or user stories) typically written in user story format. (SMART是一套创建目标（如Sprint目标）的标准。虽然invest会提醒您高质量产品积压工作（PBI）（或用户案例）的特征，通常以用户案例格式编写。)

Sprint Increment (冲刺增量) vs Potential Shippable Product (潜在可发货产品) vs MVP vs MMP

Scrum requires the team to build an incremental function in each sprint, and the increment must be deliverable, because the product owner may decide to release it at the end of the sprint. This article explains and clarify the related key concepts of: sprint increment, potential shippable product MVP and MMP. (Scrum要求团队在每个sprint中构建一个增量的功能，并且增量必须是可以发送的，因为产品负责人可能决定在sprint结束时发布它。 This article explains and clarify the related key concepts of: sprint increment, potential shippable product mvp and mmp。)

什么As / I want / so that 用户故事模板？

The most common technology is the role-feature-reason template, which is used by teams and product owners to start writing user stories in three parts: (1) As a (role); (2) I want (feature); So that (reason). (最常见的技术是角色 - 特征 - 理由模板，用于团队和产品所有者开始编写用户故事，分为三个部分：（1）作为 As a（角色）; （2）I What 我想要（特征）; So that（理由）。)

Scrum中的Burndown图表是什么？

Burndown chart is a graphical representation of the remaining work and time. It is usually used in agile software development methods, such as Scrum. However, burning charts can be applied to any project that contains measurable progress over a period of time. (Burndown chart 是剩余工作与时间的图形表示。它通常用于敏捷软件开发方法，如Scrum。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。)

Scrum中的Sprint目标是什么？

Sprint goals show the expected results of iterations that provide shared goals for the team, which must be defined before the team starts Sprint in order to focus on achieving this goal. This ensures that everyone is on the same page. After choosing goals, the team must strive to implement them. (Sprint目标显示了为团队提供共享目标的迭代的期望结果，必须在团队启动Sprint之前定义该目标，以便专注于实现此目标。这可确保每个人都在同一页面中。选择目标后，团队必须努力实施目标。)

如何使用MoSCoW方法确定产品积压的优先次序?

MoSCoW (also known as MoSCoW prioritization or MoSCoW analysis) is a prioritization technology designed to reach a consensus with stakeholders on its importance for the delivery of each requirement. (MoSCoW方法（也称为MoSCoW优先级划分或MoSCoW分析）是一种优先级技术，旨在与利益相关方就其对每项要求的交付的重要性达成共识。)

Sprint Backlog在Scrum中是什么意义？

Sprint Backlog is a set of product backlog projects selected for the current Sprint and a plan to provide product increments for achieving Sprint goals. (Sprint Backlog是为当前Sprint选择的一组产品Backlog项目，以及为实现Sprint目标而提供产品增量的计划。)