敏捷 vs 偽敏捷(3)

　　團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

　　敏捷偽敏捷有組織地回顧審視優勢，劣勢，機會和威脅，并采取行動。不是完全無組織學習經驗教訓，就是有了結論卻沒有相應的行動。每一個團隊成員都集中注意力在提高沖刺(Sprint)，發布(Release)和項目上?；仡檿h被視為敏捷的一個必需的標志，并沒有被認真對待。團隊審視所有流程，努力確保所有活動步驟是必要的，優化后的，并能帶來價值。團隊審視所有流程，努力確保沒有流程。

　　混合體 - ScrAgileFall

　　敏捷，Scrum和瀑布方法論的混合

　　它的工作原理是這樣的?用戶故事積壓在任務列表(Backlog)里并排上優先級，但特定的用戶故事累積列表有一個目標發布日期，這意味著他們都將被一起發布， 而不是單獨發布。采用沖刺(Sprint)管理開發過程中設計，編碼和單元測試階段， 另在發布之前安排一個集成系統測試，測試“在范圍內的”用戶故事所有已完成的功能。

　　(It works like this. User stories are prioritized into a backlog but there is a targeted released date for a cumulative list of specific user stories, meaning they'll all be released together instead of individually. Sprints are then employed for the design, code and unit test phases of development but an integrated system test is performed prior to the release of all the completed features for the "in-scope" user stories.)

　　瀑布地規劃和發布時間表，敏捷 / Scrum地設計和開發。

　　(It's waterfall planning and release schedules with agile/scrum design and development.)

　　敏捷軟件開發宣言

　　對流程、文檔到底意味著什么?

　　敏捷并不反對的流程。它反對沒有價值的流程，反對不能使團隊更有效的流程。

　　敏捷并不反對的文檔。它反對那些對交付的解決方案沒有幫助的文檔。

　　敏捷流程和文檔應該限制在最快的時間內交付高質量產品的最低水平。

　　敏捷測試

　　框架里的“獨立的(Independent)”測試角色

　　“獨立”并不意味著孤立一人。“獨立”是指測試團隊在價值鏈中所扮演的角色。獨立不孤立。

　　測試不能被視為“最后一關”，不能僅會在所有沖刺(Sprint)的最后進行測試。測試需要持續集成到沖刺(Sprint)的每一部分。

　　測試不能被視為我們開發和他們測試之間對抗。為了成功，必須有一個團隊意識。

　　在真正的測試驅動開發過程中，“獨立的”測試將更少地在執行測試上，而更多地在確認上。

　　敏捷工具

　　這些測試工具在敏捷開發過程中能有一席之地嗎?

　　敏捷測試工具 - Agile Accelerator 5.x

　　敏捷模板是基于Scrum的實踐(比如，沖刺(Sprint)，史詩級(Epic)的用戶故事，用戶故事等等)。

　　QC模塊自動同步，以便更容易管理沖刺(Sprint)。

　　單獨的維基接口，以便更容易管理用戶故事和任務。

　　標準的開發環境集成

　　Eclipse

　　Visual Studio IDE

　　TeamForge

　　Tasktop task-focused interface

　　敏捷表象(Façade)

　　突破表象的策略

　　敏捷教練 - 當組織投向到敏捷時，確保有一個經驗豐富的教練，然后讓他指導你的團隊!

　　風險管理 - 確保文檔的請求是根據清晰的風險理解從而判斷是否需要文檔(Make sure requests for documentation are supported with a clear understanding of the risks associated with not producing them)。當風險成真后，確保領導能夠接受影響。

　　突破職責的限制。參與到項目的每個方面。突出測試人員是解決方案的一部分，而不是問題的一部分。

　　故事復查(Review) - 主持正式和非正式用戶故事的復查會議，以幫助確保每個人都有同樣的理解。

　　結對測試 - 就像結對編程有助于提高開發的代碼質量，結對測試能確保更好的測試覆蓋率。一個開發人員搭配一個測試人員。

　　促進采用工具和方法論的“最佳實踐”。促進利用之前那些離開的人的經驗。

　　回顧會議 - 認真吸取經驗教訓。確保建立由PM或Scrum Master跟蹤的并可操作的計劃。

　　面對殘酷的事實，但從不放棄希望。

　　度量，度量，度量 - 沒有度量將一事無成(What get meatured gets done)。開始測量你的敏捷過程的有效性。

　　實現之后：事件與變更請求(Post Implementation: Incidents & Change Requests)

　　沖刺(Sprint)計劃與實際情況

　　沖刺(Sprint)的測試計劃與進度

　　不要成為受害者 - 控制你自己和你的團隊。如果你需要，做好保衛它的準備，然后做好自己的事情，堅持不懈，以幫助你的項目成功。

　　譯者注：

　　敏捷是一個熱門、有爭議的問題，文中觀點僅為原文作者觀點(當然不排除我的錯誤理解)。去年看到這篇好文，一直想翻譯下，跟大家一起分享分享，由于種種原因，直到今天才搞定，雖然很晚了，也算了卻一樁心愿。

　　此文來源一個PDF，格式自己用HTML實現，可能會有些問題。如果發現請大膽指出來。翻譯得不好地方，也請指正。

　　原PDF上的時間: 10/2/2012

　　原文連接：http://www.softwaretestpro.com/Item/5727/Session-404-Agile-vs- Fragile-A-Disciplined-Approach-or-an-Excuse-for-Chaos---Brian-Copeland/Software-Test-Professionals-Conference

原文轉自：http://blog.csdn.net/ocean1ee/article/details/8873688