無論是創業軟件團隊，還是企業級規?；浖邪l，都會遇到提升管理能力、提升研發效率的問題。為了解決這兩個問題，許多軟件研發工具平臺也營運而生：微軟、IBM、HP、Atlassian、Rally、Collabornet、Polarion……等廠商都推出了各具特色的產品，而近年來新生的Slack、teambition等平臺也帶來了新的理念和產品，受到了許多團隊的歡迎。作為軟件研發的團隊或企業，我們該如何根據自身發展情況，對這些產品和工具進行合理的選擇？一個支撐軟件高效研發的工具平臺應該具備哪些特點？未來又將向什么方向發展呢？
世界范圍內軟件研發工具平臺產品發展迅速，國內產品仍是空白
當我們在學校里用Visual Studio編寫hello world的時候，我們就已經開始使用工具進行軟件研發。只是那個時候，工具的作用還很單一，對管理能力、研發效率的整體提升還沒有特別關照。
在80年代，國內的計算機、軟件行業剛剛萌芽的時候，國外的同行已經開始研究使用工具提升軟件研發效率，微軟、Rational（后來被IBM收購）推出了各自的IDE，并在不斷增強IDE功能的同時，向需求管理和質量管理方向拓展。
90年代，又有一些廠商加入到了開發軟件研發工具產品的行列中，其中國內同行非常熟悉的莫過于Mercury（后來被HP收購）的產品，90年代末和2000年前后，大家經常使用的研發工具組合一般是：需求管理用Rational Request Pro，開發IDE用Micosoft Visio Studio，代碼庫用collabnet subversion或Rational Clear Case，測試管理用Mercury Test Director，軟件性能測試用Mercury LoadRunner。這些工具在軟件研發的每個方面都提升了個人和團隊的效率，也讓越來越多的人看到了工具平臺對軟件研發效率提升的重要性。
進入21世紀，敏捷思想及敏捷軟件研發方法開始逐漸改變人們對軟件研發的認識。在軟件研發工具平臺方面，ALM（Application Lifecycle Management）逐漸成為各工具廠商產品努力的方向。在短短的10年內，涌現出一大批優秀的軟件研發工具平臺廠商，如Atlassian、Rally、Polarion、Versionone、Serena……一些老牌廠商，如微軟、IBM、HP通過收購、合并、開發新的工具產品等方式，更加完善了軟件全生命周期管理的工具平臺。有了新的軟件研發方法，配合眾多優秀的軟件研發工具平臺，軟件行業得到了快速的發展。此時國內同行也廣泛認識到工具平臺對提升研發效率的重要性，有條件的企業或采購，或自主研發，搭建起自己的研發工具平臺。
2010年前后，隨著互聯網的蓬勃發展，互聯網軟件研發逐漸成為新的焦點，DevOps很快成為大家普遍的共識。很多傳統軟件研發工具廠商打著“DevOps”的旗幟適時地推出了一些產品或升級版本，同時又有一些新的廠商加入競爭的行列。在如何能夠更好地管理軟件研發活動的問題上，像Slack這樣的產品向“傳統”研發工具平臺發起了新的挑戰，在看到越來越多的軟件研發團隊更愿意使用Slack進行日常研發工作時，我們不禁陷入思索：未來軟件研發工具平臺將何去何從？
圖1
目前軟件研發工具平臺的對比研究有很多，但實用性低
2010年以后，多家重要的IT咨詢公司分別開始定期發布主流軟件研發工具平臺對比研究報告，各家最近一期的報告結果匯總如下：
圖2
這些報告每一篇報告單獨看似乎視角都很客觀，評估方法似乎都很縝密。但當把他們放到一起比較后，會發現它們的結論大相徑庭，不同的廠商也會精心挑選“適合”自己產品的報告，懸掛于自己的產品網站首頁。而這些只有兩個維度的魔力象限對于真正需要軟件研發工具平臺的團隊或企業來說，幫助并不是很大。
我們發現這些IT咨詢公司評判軟件研發工具平臺廠商，及其產品的視角無外乎有兩個：一個是從ALM的功能視角；另一個是商業的視角。在ALM功能視角下，各家咨詢公司會分別著眼于軟件的需求、設計、開發、測試、發布等幾個主要環節，詳細對比各個廠商的產品功能，看誰的功能更強大，誰的功能更全面。而在商業的視角中，他們則更多以產品的市場份額、廠商服務的覆蓋程度以及盈利的多少、來衡量哪家廠商更加優秀。這樣就造成了功能越齊全的產品、體量越大廠商的在類似的比較報告中越得到好評，反之則被排在后面。
但是，對于正在尋求軟件研發工具平臺解決方案的團隊和企業來說，尤其是正在進行敏捷、互聯網轉型的團隊或企業來說，上面的這些對比方法還是顯得陳舊、粗獷，并沒有解答哪個工具平臺更加適合我們這些正在進行敏捷軟件研發，或者互聯網軟件研發的團隊。
在敏捷軟件研發的影響下，工具平臺發生了很大變化
傳統瀑布模式下的軟件研發，注重軟件從概念到上線的流程以及每個流程節點上的關鍵活動，同時也重視項目的管理。許多支持瀑布模式開發的軟件研發工具平臺，在需求管理、質量管理、配置管理、項目管理等方面的功能都十分強大。
圖3
敏捷思想強調“以人為本”，讓人們主動、自我管理、響應變化、互相信賴地工作。敏捷軟件研發方法，如Scrum、Kanban、XP實踐等指導軟件研發團隊擁抱需求變化，快速交付客戶價值，持續改進。要想使團隊或組織真正敏捷起來，需要在人、技、法三方面達到和諧。這就需要軟件研發工具平臺這個“技”的方面也要敏捷起來。
圖4
敏捷宣言的第一句話是：“個體和交互勝過流程和工具”，但這并不是說敏捷不需要工具的支持。相反，如果有了更好地研發工具支持，提高團隊的工作效率，才能真正的敏捷起來。
對照敏捷宣言的幾句話，我們大致能看到敏捷價值觀下的研發工具應該具備的特點：
1. 個體與交互勝過流程和工具：研發工具應該能夠突出個人的工作，并且能夠讓團隊更好地協作
2. 工作的軟件勝過詳盡的文檔：研發工具應該精簡文檔及審批流程，讓軟件交付更加順暢
3. 客戶合作勝過合同談判：研發工具應該支撐快速交付可工作的軟件，并且能夠更好地幫助用戶反饋
4. 響應變化勝過遵循計劃：研發工具應該打通需求、設計、開發、驗證的循環，持續交付
同時，我們看到越來越多的工具平臺正在發生如下的變化：
強化：
1. 對敏捷軟件開發實踐的支持
2. 對持續快速交付的支持
3. 對團隊協作的支持
4. 對用戶反饋的支持
5. 用戶體驗的提升
6. 單一工具解決特定問題，平臺提升整體效率
弱化：
1. 流程及審批
2. 文檔及變更管理
3. 基于時間的任務項計劃管理（甘特圖）
4. 把產品質量問題交給測試人員
5. 項目中角色及權限劃分
6. 大而全的平臺解決所有問題
以上的變化讓我們清楚地看到敏捷研發給工具平臺帶來的變革，我們也可以總結一下，敏捷方法下的軟件研發工具平臺應該具備以下6個特點：
1. 敏捷管理實踐（用戶故事地圖、故事列表、優先級、估算、卡片墻/看板、燃盡圖/CFD、回顧數據）
2. 敏捷開發實踐-代碼（IDE集成、代碼掃描、代碼審查）
3. 敏捷開發實踐-Dev-Test-Ops的Pipeline效率提升（編譯、CI、UT、AT、發布、部署、運維）
4. 用戶反饋與研發流程打通
5. 注重協作與用戶體驗
6. 團隊能負擔的工具平臺價格
主流敏捷軟件研發工具平臺比較，各有所長
圖5
上面的表格是我們基于敏捷研發方法下的工具平臺應具備的功能，結合對每個工具平臺的深度試用或試用后做出的比較。看到在敏捷研發的場景下，各家平臺的功能各有所長。
圖6
選擇適合自己團隊的軟件研發工具平臺
在軟件研發工具平臺中，沒有通用的最完美的解決方案。錯誤的選擇會讓組織的成長、競爭以及產品的成功交付受到影響。
在選擇軟件研發工具平臺時，先要確定使用工具平臺想要使組織在哪方面得到提升，是快速交付的能力？還是為了支撐敏捷開發實踐？或是敏捷管理實踐落地？還是為了更好地收集管理用戶反饋？亦或是為了加強團隊協作？
確定了目標，還要結合人技法三角，綜合考慮用什么樣的工具，即“技”。要充分了解三角的其它兩個方面，也就是了解團隊或組織的人的能力水平，和目前大家使用或將要使用的研發方法。
只有在人、技、法三方面達到和諧，才能充分地發揮工具平臺的效果，才能真正解決問題，使組織的能力得到提升。
軟件研發工具平臺未來的發展
隨著軟件行業的迅猛發展，軟件研發工具平臺也必然會發生更多的變化。未來的軟件研發工具平臺將會更加突出如下特征：
1. 更快
在需求、設計、開發、測試、部署、反饋的軟件研發周期中，研發工具平臺會更多提高研發整體效率，進一步縮短研發周期。
2. 質量風險前移
在代碼檢查、CR、CI、單測、自動化功能、性能測試、安全測試等方面，研發工具平臺會更注重質量風險的前移，即在開發階段保證質量的優秀實踐的落地。
3. 更多協作
在團隊協作、客戶合作方面，研發工具平臺會更好地結合網絡社交、移動互聯網等新業務新技術，讓軟件研發這種人與人的協作活動更順暢、更方便。
作者簡介
王一男，百度研發工具平臺資深產品經理。10年軟件敏捷研發管理實戰經驗，先后在兩家上市企業成功實施基于信息化工具集的軟件敏捷項目管理，并成功實現了基于信息化數據的項目持續過程改進。
本文選自程序員電子版2015年12月B刊，該期更多文章請查看這里。2000年創刊至今所有文章目錄請查看程序員封面秀。歡迎訂閱程序員電子版（含iPad版、Android版）。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
