最近一直在研究軟件開發的過程管理體系，如何能夠幫助開發團隊實現開發規範的落地，開發效率的成倍提高，同時又不會讓開發人員用起來不是累贅。研究了市面上不同的管理工具，今天就給大家分享一下百度上廣告比較多的一個產品：碼市。
註冊了一個體驗帳號，看到的第一個功能是項目管理，這個功能是絕大部分軟件開發管理工具的必備功能。從免費的禪道，到其他各種收費的項目管理工具，感覺功能都差不多，無非就是需求管理、任務管理，BUG管理等。相對於傳統的單機版項目管理工具，碼市的項目管理模塊還是使用起來很方便，也很人性化的。同時適合在線多人，團隊之間的協同。
代碼倉庫管理是整個軟件開發的核心，碼市這塊封裝了一層GIT，不用自己建立代碼倉庫服務器了，而且通過WEB方式就可以配置好GIT倉庫，還是很方便的。除了提供了代碼倉庫空間，其他的功能跟直接用GIT命令或客戶端，差別不是特別大。
另一個比較大的功能是持續集成，沒太理解它的作用，我估計是代碼倉庫跟測試服務器之間的一個持續集成的配置，可以代碼一提交，在測試服務器就能集成好並通過地址可以直接訪問，不需要在本地再部署調試環境了。
基於容器的在線部署，也就是DEVOPS能力，這是一套自動化部署的體系，讓開發人員不用直接接觸生產服務器，就能把測試好的代碼，直接部署到生產服務器，避免各種安全隱患，還是很有用處的。在小公司一般都是開發人員直接用ROOT連接生產服務器，在生產服務器隨便折騰，特別容易造成生產服務器的安全隱患，程序或數據的刪除等等。通過DEVOPS體系就能大大減輕開發運維人員的工作，並能提高生產環境的安全性。這個是好功能。
製品庫沒搞明白是啥東西，大概是保存了不同版本的生產服務器版本，可以方便的在不同版本之間隨意切換代碼。
測試模塊，主要是測試用例及測試計劃的管理，也沒什麼特殊的地方。
從功能上分析，這個產品涵蓋了需求管理，項目管理，測試管理，運維等工作，還是很全的。但是根據我多年的團隊開發經驗來看。這些工作會額外增加開發人員的很多工作。比如需求管理，傳統做法是我做好原型，做好PRD就好了，如果用這個工具，還得把需求一個一個錄進去，會額外增加工作量。特別是對於開發人員來說，每天上來提交開發任務和進度，會成爲一個負擔，最後就是流於形式，就像很多開發團隊的日報一樣，每天做的事情都差不多，發日報就是應付差事。所以沒有從根本上解決開發的效率。
最近看了一篇阿里團隊內部敏捷開發的方法體系，感覺收益很多。軟件開發目前要解決的不是所謂的項目管理工具問題，而是理念的問題。
首先從甲方角度（公司內部稱爲需求方），做了很多無價值的需求，以及需求不停地返工。因此發生在軟件開發之前的需求澄清工作至關重要，在軟件研發過程中，大多數的時間浪費在需求的反覆確認和澄清過程中。
如何做好需求澄清呢？就是實例化需求，是業務、產品、開發和測試一起坐在一起，從場景出發，以用戶的操作實例來澄清需求。實例是具體的，其典型形式是：“在什麼情況下，做什麼操作，會得到什麼結果”。基於具體的實例，更加便於溝通中的雙向確認，保證理解的一致和場景覆蓋。
需求澄清是需要甲方多個角度的配合和溝通的，這也是目前外包市場失敗的主要原因：甲方的需求只是簡單的幾句話，然後包含無限的含義，讓開發團隊去猜測去簡化，造成需求澄清不了，從而扯皮。
其次，驗收測試驅動開發
- 需求進入開發團隊的隊列（等待開發）後，業務、開發和測試立即通過實例化需求活動澄清需求，用結構化的方式生成需求的驗收標準。
- 在開發實現這些需求的同時，團隊會將這些需求實例會轉化成測試用例，並把部分測試用例自動化，做到功能實現和自動化測試開發同步完成。
- 需求實現完成後，團隊會有加工好的測試用例來驗收這些需求。甚至可以將部分測試用例提前給到開發人員，讓開發提前進行自測。
並且這些測試驅動的過程，能利用自動化手段，無時不刻的在測試開發的程序是否正確。
最後，任務的小粒度拆分，甚至到小時級別
在整個迭代過程中，團隊以小粒度的需求爲單位開發，持續地集成和測試它們，即時發現和解決問題。
唯有實現了這些開發的功能和一些自動化手段的工具，才能真正提高軟件開發的質量，真正實現開發效率的倍增。僅僅是一個項目管理工具和代碼管理工具，不會有多大的作用。
以上是個人的觀點和研究，歡迎大家的拍磚和點贊。