5關於敏捷開發的常見誤區
經過多年看到大量IT項目失敗後，一群經驗豐富且得到認可的軟件開發“專家”遇到了“需要替代文檔驅動的重量級軟件開發流程”。根據他們過去的經驗，他們他們同意了一套他們稱之為敏捷宣言的基本準則：
- 個體和交互比過程和工具
- 通過綜合文檔工作軟件
- 客戶合作過合同談判
- 響應改變了遵循計劃
而且好像他們曾預料到這種簡單可能導致誤解，他們補充說他們確實看到了右邊項目的價值，但左邊的項目更有價值。
因此，雖然他們只是表示偏好一個項目而不是另一個項目，但它偶爾會被解釋為一個或兩個選項，使兩個項目互為排他性。“Over”被“而不是”取代。
例如，意思是“我寧願靈活地將變化納入而不是堅持嚴格的計劃”會錯誤地變成。“我想回應變化因此我不需要一個計劃，”這讓我們對敏捷開發最常見的誤解之一：
誤解＃1：敏捷不需要任何計劃
為了理解規劃在敏捷中的運作方式，我們首先來看看如何在傳統的瀑布環境中進行規劃。
預先創建詳細計劃以測量進度，檢測偏差並預測結果。儘管進行了細緻的規劃，但是大量的軟件開發項目導致了代價高昂的延遲，這導致了這種可預測性似乎僅僅是一種感知的結論。
此外，由於傳統環境中沒有機制允許將學習整合到計劃中，因此預測不一定會變得更加準確。
另一方面，在敏捷環境中，人們普遍認為軟件開發是一個複雜的過程，具有一定程度的不確定性。
因此，規劃在項目開始之前進行到很小程度，並且主要在整個開發過程中以漸進方式進行。
這是如何實現的？由於快速迭代和功能驅動開發，客戶反饋等新數據很快就可用，支持短期和長期規劃。團隊可以訪問真實數據，而不是做出假設，從而可以更準確地預測他們將要提供的內容。
通過不斷規劃，估算，確定優先順序和交付預測，可以顯著改善。
誤解＃2：敏捷不需要文檔
花費數小時編寫冗長需求文檔的開發人員和精心跟踪他們的開發人員都知道在開發期間或功能發布後發現需求誤解的挫敗感。
這既不是利益相關者也不是開發團隊的錯。書面文字需要解釋。以蘋果為例：雖然你和我都知道這是什麼，但你可能會考慮到甜紅色，而我更喜歡略帶酸味的綠色。
這就是為什麼敏捷促進團隊之間的對話，以便在客戶，利益相關者，產品所有者和每個開發人員之間達成共識，從而確保每個人在實現目標的同一頁面上。
但這並不意味著敏捷項目中根本不需要文檔：用戶故事被添加到待辦事項中，繪製線框圖，創建用戶流程圖，與客戶進行修飾會議並將結果記錄在無論哪種形式都適合該項目。在衝刺之前和衝刺期間，商業和技術細節會添加到Jira門票中。與規劃一樣，敏捷文檔也會在需要的範圍內逐步進行。
如果對此類文件的必要性存在分歧（通常在產品所有者和團隊之間），Mike Cohn 建議兩條準則：
- 如果開發團隊發現在開發過程中記錄它很有用，例如源代碼，設計指南或他們認為對軟件維護有益的任何東西，他們自然會這樣做。
- 如果產品所有者或利益相關者需要一份文檔，例如，描述團隊無法生成的數據庫表和字段的文檔，則將其作為任務添加到待辦事項中。
誤解＃3：敏捷不適用於截止日期的項目
“什麼時候完成所有工作？”很可能是管理層和企業主在項目啟動之前提出的第一個也是最緊迫的問題之一。無論該日期是粗略估計，純粹的“願望日期”還是外部強加的日期，總會有預期發布日期的預期。
要了解截止日期和敏捷如何結合在一起，讓我們首先看看在傳統的非敏捷設置中如何處理截止日期。
在傳統方法中，所有需求都在項目的最初階段確定，成功是根據實施這些需求的數量來衡量的。在項目結束時，一旦截止日期臨近，這些項目往往依賴於大量加班。雖然這可能會在短期內提高生產率，但項目完成後的生產力損失會產生巨大的成本。
敏捷項目自然也是從一個巨大的功能願望列表開始的。通過考慮廣泛的選擇，我們正在努力確保我們不會忘記必要的選項。然而，那些必須按客戶價值優先考慮，並且有必要確定哪些是真正需要的。
敏捷方法承認，在項目之前可能被視為必不可少的功能可能會根據從這些功能的早期和頻繁發布中收集的反饋而發生變化。短暫的迭代和工作軟件確保我們有一個經過測試的工作產品，可能包含客戶在截止日期到來時想要的功能。
但是，可能存在一些項目，它們不是削減範圍的選項，而是僅啟動和運行主要的重要功能。迭代方法的一個好處是可以在開發過程的早期注意到延遲。因此，很可能仍有足夠的時間來調整資源。如果早期對這些警告信號作出反應，那麼更多開發人員放慢流程而不是加速流程的原則並不適用。
誤解＃4：敏捷開發是有效的
讓我們首先回顧一些術語的實際含義，以便我們都在同一頁面上。據Oxford Living Dictionaries稱，定義如下：
“有效。成功地產生了預期或預期的結果。
高效。（系統或機器）以最小的浪費或費用實現最大生產率。（一個人）以有條理和有能力的方式工作。“
因此效率意味著我們如何利用我們的時間，而有效性就是實現特定目的。
為了正確看待這一切，讓我們看看構建正確的東西的兩個概念，即開發客戶需要和想要購買的產品，而不是正確地構建產品，這意味著以有效的方式構建產品，而不是浪費時間和資源。
效率低下無效：錯誤地做錯事 - 不用說 - 不可取。
高效但無效： 做錯事但做得很好。我們很有效但我們做的事情沒有人想要。
低效但有效：我們正在建立正確的事情，但效率低下。絕對比以前更好的位置，因為我們賺錢讓我們有時間變得更有效率。
高效和有效：絕對是我們想成為的地方：做正確的事情，做正確的事。這就是我們構建客戶喜愛的產品的地方。
故事的士氣是：沒有效率，效率就沒用了。
那麼Agile沒有效率的地方嗎？有一種方式，而不是在敏捷環境中建立的儀式和流程，例如更高效的站立，回顧，規劃和部署流程。
誤解＃5：敏捷永遠比瀑布更好
正如我們之前所見，如果你是一名效率迷，敏捷將不會是你的首選。但哪一個真的更好？是否有適合瀑布的項目？
敏捷和瀑布是這樣的對立面，很難說哪一個更好。這實際上取決於項目，需求的清晰度以及您的靈活性。
如果您對最終產品應該是什麼有清晰的了解（例如，如果您以前做過很多次），或者您有固定的要求不會改變，有些人認為瀑布是比敏捷更好的選擇。如果您有高度的信心，瀑布是一個簡單，高效的過程。當你必須適應變化時，瀑布的問題就出現了。
當不清楚最終產品的外觀，可能發生的變化以及手頭的項目是否具有顯著的複雜程度時，敏捷應該是您的首選。瀑布不允許回到完成階段並在沒有大量返工和增加成本的情況下進行更改，而敏捷方法允許處理新問題和調整需求，並且可以幫助降低變更成本和不確定性。
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 任务板) 是一种工具, 可帮助团队使冲刺积压工作项可见。该板可以采用许多手动 (即白板和贴纸) 和虚拟表单 (即软件工具), 但无论外观如何, 它都能执行相同的功能。)
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 ”)
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 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）（或用户案例）的特征，通常以用户案例格式编写。)
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。)
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（理由）。)
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。但是，刻录图表可以应用于任何包含一段时间内可衡量进展的项目。)
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 (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 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目标而提供产品增量的计划。)
posted on 2019-02-11 15:50 Lynch_Warren 阅读(196) 评论(0) 收藏 举报
浙公网安备 33010602011771号