企业的任何方法均可融入敏捷技术
【TechTarget中國原創】許多組織面臨采取敏捷的挑戰，特別是當他們試圖完全取代一個熟悉的傳統方法時。為了緩解調整，管理者可以考慮采用敏捷的原則，可以無縫集成現有方法。
軟件開發的瀑布模型和其他非敏捷方法工作得很好，因為在寫一行代碼前，他們強制創建部分或全部要求，功能規范，技術規范和技術架構文檔。然而，他們不能很好的工作，因為往往在軟件交付之前你需要等待幾個星期或幾個月，并從最終用戶那里發現自己一直偏離航向。敏捷方法將結束這種閉塞的通信缺口。
敏捷開發者做了一個發布版本和演示，讓最終用戶可以操作使用，并且在開發周期的早期需要做的航向修正方面提供反饋。你并不需要等待數周或數月來發現，開發的軟件是偏離航線的。最終用戶能夠更早的使用軟件并且在你是否處于正確方向上提供反饋。
在軟件開發工作中，最終用戶和開發團隊之間的溝通是最大的問題。如果你早日解決通信問題，那么開發工作將更加順利。敏捷背后的主要原則之一是杜絕任何程序后面的浪費。浪費可以有許多形式——比如說不必要的和浪費的人力資源，軟件代碼的延誤和返工方面的時間浪費。
你可以用下面的方法把敏捷方法背后的基本原則融入到其他方法中：
消除一切不必要的和表面文章的文檔：功能規范，技術規范和技術結構文檔都應該是可選的，要根據具體情況選擇性使用。如果是一個持續時間短的項目，所有這些文件應該全部消除。其中的每一個文件都應該考慮其效用，在我們開始編碼之前，組合成一個或者全部消除。
盡快創建一個臨時湊合的（水平不高的）的文件來闡明設計：一旦我們過了規范階段，每一個項目的開發團隊創建一個高層次的設計文件，即使它僅僅只有幾頁。這只是用戶界面的功能模型設計。究其原因，是為了最終用戶能夠盡早得到一個用戶界面的預覽。開發團隊得到一個問問題的機會，并在進行編碼之前把所有事情闡明清楚。
增加定期構建和發布以供交流和提高代碼質量：不要在版本發布之前等待幾個月，做一個項目計劃，把開發和測試劃分到周，10天，或最多每兩周建立一個發行周期。在這些日子里，如果沒有失敗，就是一個發行版本。這樣做的原因是灌輸生成和發行的紀律。每一個版本只有正式測試，本地化才能發布。這也保證了軟件測試比在一個純粹的瀑布模型次數多，并間接的提高了軟件的質量。
使用在線，自動化的問題/缺陷跟蹤系統以便更好更快地溝通：溝通速度是敏捷方法的最大好處之一。問題，爭議和缺陷能夠更早的得到溝通和解決。一個自動化，網絡問題/缺陷跟蹤系統，很好的與電子郵件系統集成，當和其他方法整合時，實現相同的益處還有很長的路要走。
把項目狀態會議改成半站立會議：敏捷站立會議有助于在開發周期的早期階段識別問題和障礙，解決這些問題并掃除障礙。開發團隊甚至可以每天做敏捷站立會議。當使用其他方法時，每日站立會議是沒有必要的，但是把項目狀態會議周期從每月或每季度到每一個或兩個星期，同樣可以達到目標。
通過跟蹤發布完成的功能衡量項目速度：當敏捷項目經理通過跟蹤構建和發布完成的故事來衡量項目速度時，他們對開發進度快慢會有一個認識。團隊使用其他方法可能也需要對每一個版本他們完成了多少功能有一個認識。增加發本的頻率比以前更能幫助跟蹤項目速度。
總結
敏捷方法幫助彌合交流缺口，更早的識別技術困難和用戶界面問題。他們還消除了很多不必要的文件浪費，不必要的，浪費的設計和編碼的努力。頻繁的發布和項目管理會議，確保更早的確認和確定航線修正。通過識別什么與敏捷方法一起工作，和為什么一起工作，當使用其他方法時同樣可以逐漸的融合。
TechTarget中國原創內容，原文鏈接：http://searchsoa.techtarget.com.cn/showcontent_64705.htm
轉載于:https://blog.51cto.com/loong460/1059177
總結
以上是生活随笔為你收集整理的企业的任何方法均可融入敏捷技术的全部內容，希望文章能夠幫你解決所遇到的問題。
