本文將主要針對Android軟件開發(fā)進行詳細分析討論，從現(xiàn)有敏捷團隊的問題及解決方法進行分析，希望能給各位帶來幫助。

敏捷團隊，一個以產(chǎn)品功能迭代為核心驅(qū)動力的團隊，他們的目標是快速迭代出用戶需要的新功能。這個目標當然沒有問題，但是卻與開發(fā)高質(zhì)量的軟件這個目標相沖突。合理的化解這個沖突，改善軟件開發(fā)質(zhì)量，這就是本文的重點。

1.現(xiàn)狀

在闡述問題之前，有必要先說明一下當前團隊的結(jié)構(gòu)與運作過程。為了能更細致的說明問題，本文將主要針對Android軟件開發(fā)進行詳細分析討論，以下是當前的人員組成結(jié)構(gòu)圖：

1.1.當前存在的問題

功能迭代只見樹木，不見森林

身處于迭代開發(fā)的軟件開發(fā)人員，往往只了解自身功能的需求，然后根據(jù)對應的需求進行設計，容易導致一些不合理的設計，輕則導致后期維護問題，或者一些小概率事件導致的bug問題，重則導致功能重新設計開發(fā)，影響迭代速度。

功能完成為主要業(yè)績，軟件高質(zhì)量為次要業(yè)績

功能完成是一個比較容易考察的指標，而軟件高質(zhì)量卻不是，如果還主次有別，軟件高質(zhì)量將無法有效的執(zhí)行完成。

忽視性能問題，總是事后處理

以快速完成功能為目標，往往為了進度在性能這塊做妥協(xié)，總是在出現(xiàn)很明顯的性能問題時，才進行對應的優(yōu)化，導致應用性能越來越差。

隨著開發(fā)團隊規(guī)模變大，規(guī)范推動執(zhí)行難度也越來越大

受限于溝通成本，人員迭代功能的實際工作任務，審查的復雜度的增加，這塊越來越難以實際執(zhí)行。

工作量評估不準確

由于參與實際迭代的開發(fā)人員個人能力的差異，不能很好的量化實際工作量。

交互不合理時，不能有效的溝通，提供合理的建議

開發(fā)人員與交互溝通時，往往會向交互妥協(xié)，或者直接否定，導致一些不合理的交互設計方案出現(xiàn)。

部分可重用的組件，重復開發(fā)

開發(fā)人員受限于對團隊的了解情況，受限于共用庫的維護情況，受限于個人的意愿，導致部分重復開發(fā)工作。

單元測試基本無法實際執(zhí)行

受到開發(fā)進度的逼迫，以及考核的指標的影響，單元測試無法實際執(zhí)行。

1.2.總結(jié)

問題有很多，其中最大的問題是對軟件人員的業(yè)績評估方向出了問題，或者軟件人員的工作重心出了問題。當前Android開發(fā)人員以完成迭代功能為主要工作重心，認為自己的迭代功能完成了，業(yè)績也就實現(xiàn)了。所以，解決這個根本性問題，才能有效的開發(fā)出高質(zhì)量的應用。方向不正確，再多的努力也起不到應有的效果。

2.理想中的工作狀態(tài)

夢想還是要有的，萬一現(xiàn)實了呢？想要在某一方面有所成就，就需要持續(xù)不斷的在某個領(lǐng)域進行研究和思考。想要提升應用開發(fā)的效率，提升應用的運行性能，提升應用的可靠性等，都需要在應用開發(fā)上做持續(xù)深入的研究，不是一個人研究，而是整個團隊持續(xù)不斷的深入研究，逐漸沉淀，持續(xù)改進。

人們眼中的天才之所以卓越非凡，并非天資超人一等，而是付出了持續(xù)不斷的努力。1萬小時的錘煉是任何人從平凡變成超凡的必要條件。–丹尼爾·科伊爾

• 產(chǎn)品問題隨著時間的推移越來越少。
• 開發(fā)效率隨著技術(shù)的沉淀不斷積累，不斷的提升。
• 不做重復的優(yōu)化工作。
• 不踩同樣的坑。
• 開發(fā)人員的專業(yè)領(lǐng)域越來越深入，找到個人成就感。
• 開發(fā)人員之間可以互相支持，人員之間互相備用，基本不受人員流動影響。
• 產(chǎn)品都是通過了單元測試、接口測試的。
• 軟件開發(fā)方案均得到充分的評估，不因為方案問題而返工。
• 規(guī)范都能實施到位。
• 性能優(yōu)化，開發(fā)質(zhì)量等問題大部分都能在開發(fā)過程中解決。

3.向著理想奮斗

敢想敢做，目前需要對現(xiàn)有團隊結(jié)構(gòu)做一定的調(diào)整，具體的調(diào)整如下：

看似小的調(diào)整，卻有著本質(zhì)的不同，以前的Android開發(fā)團隊只提供共有的開發(fā)類庫，其他事情均有對應的開發(fā)人員搞定，引起了很多不確定因素。現(xiàn)在由領(lǐng)域小團隊全權(quán)接手，Android組裝者的工作更多的是小部分業(yè)務邏輯，任何一個功能基本上都有多個專業(yè)團隊的人協(xié)作完成。以前一個功能負責人需要完成90%的代碼，10%的代碼由團隊提供，經(jīng)過這樣的調(diào)整過，我們希望達到功能負責人只需要完成10%的代碼，其余90%由各領(lǐng)域團隊提供，讓專業(yè)的人做專業(yè)的事。

3.1.調(diào)整的意義

• 調(diào)整考核指標，后期Android團隊以開發(fā)人員在其所在領(lǐng)域的成就為主要考核指標，敏捷迭代功能的開發(fā)工作為次要指標。
• 將Android團隊所有領(lǐng)域細分化，并分配到幾個領(lǐng)域小組中進行持續(xù)研究和開發(fā)，不僅僅限于公共庫，也包括業(yè)務功能邏輯的開發(fā)。
• 明確各自的職責，也明確了各自的業(yè)績和自身的發(fā)展方向。
• 專業(yè)領(lǐng)域由專業(yè)的人做，降低功能開發(fā)時設計的缺陷，也讓整個團隊的能力能有效的提高。
• 領(lǐng)域?qū)I(yè)化，每個領(lǐng)域都有幾個開發(fā)人員，形成人員互備，降低人員流動風險。
• 領(lǐng)域?qū)I(yè)化后，更有利于推動單元測試、接口測試、代碼審查、性能優(yōu)化、規(guī)范執(zhí)行等事項。

3.2.細分領(lǐng)域

以下是目前領(lǐng)域細分的一個范本，它僅僅代表了一個方向，領(lǐng)域的細分不是一蹴而就，需要逐步完善。

4.調(diào)整后的主要問題

經(jīng)過這樣調(diào)整后，一個app的開發(fā)往往有一個功能負責人和幾個領(lǐng)域的相關(guān)人員參與需求評審，然后幾個開發(fā)人員根據(jù)需求和自身的專業(yè)領(lǐng)域共同設計和執(zhí)行開發(fā)。領(lǐng)域團隊的人員負責提供對應的開發(fā)庫，或者提供對應的技術(shù)支持協(xié)作開發(fā)。這樣做，增加了部分溝通成本。但是，我相信隨著該模式的持續(xù)運作和改善，隨著各個領(lǐng)域逐漸的專業(yè)化，軟件的整體的開發(fā)效率和穩(wěn)定性會相比于現(xiàn)在有明顯的提高，值得一試。

本文由 @空穴來風 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。