敏捷開發(fā)的常見誤區(qū)-資料下載頁
2025-06-20 06:59本頁面
【正文】 ，混亂。在Android上，你可以自行發(fā)布更新，但如果基于iOS的，在Apple的App Store上發(fā)布，別說每天一個版本，就算每周一個版本，Apple的軟件審核流程還沒走完，就又扔一個新的版本，這就很容易造成下游工作根本沒法正常進行。將版本更新速度視為敏捷開發(fā)，是完全錯誤的。敏捷開發(fā)在于你能夠準確抓住市場，在時間窗口內快速推出產品。由于市場的不確定性和用戶喜好/需求的不確定性，用戶通常不清楚需要什么，你先給他，他再去判斷，這需要在需求開發(fā)市場驗證中進行循環(huán)迭代，以用戶為最終目標，而不是機械地將敏捷視為快，而判斷什么為快，又機械地用版本推出速度來說明，每天推一個版本，只能說明開發(fā)流程出了問題，整個學生小作坊。敏捷開發(fā)也仍然是和版本更新有一定的關系。但這個版本，不是小修小補的小版本，而是有新功能，新UI，新互動方式，在用戶體驗上有新的感受。這樣的版本，不可能一兩天就升級。另外，你推給客戶的都應該是個穩(wěn)定的版本。18. 誤區(qū)：沒有分析和設計敏捷開發(fā)強調簡單設計，團隊每個成員都從接觸客戶到分析設計，到編碼，全部承擔。但是實際上團隊成員的素質參差不齊，如果只有簡單設計、立即編碼，而沒有后續(xù)的持續(xù)重構等實踐，將導致設計混亂不一致，尤其是對老系統(tǒng)的功能升級，如果對原有系統(tǒng)的影響分析不夠，弱化了分析設計，將導致很多工作在后期頻繁變更，使得團隊的挫折感增強，產生較多的重復工作和浪費。必要的系統(tǒng)架構和設計從來都是非常重要的。只是這里的分析設計有別于傳統(tǒng)的開發(fā)模式，應該應用敏捷的思想，簡單設計，持續(xù)重構，盡快反饋等。19. 誤區(qū)：敏捷擁抱變化，因此前期需求可以隨意簡單因為敏捷的導向，可能造成的問題是，前期需求比較隨意，對需求質量的控制弱化，需求變更更加頻繁，但是這并不意味著對需求可以不做深究，甚至可以隨意變更需求。（1）需求質量的審核，仍然需要改進，需求方向性的錯誤將導致后續(xù)一系列的工作浪費，所以團隊內部應該設定里程碑和review標準，從而確保基本的需求質量。（2）在Iteration里需求盡量不要變更，明確Iteration的邊界。否則頻繁的變更導致團隊沒有成就感，方向和目標不明確。（3）敏捷講求業(yè)務價值導向，有些變更從業(yè)務價值上看，可能并非真正需求急切變更。有些變更通過更好的Impact分析和設計應該也可以避免。BA和SA等不同的角色應該一起配合來做出Impact分析，以供決策。20. 誤區(qū)：可以孤立地實踐少數(shù)的敏捷實踐一些敏捷實踐容易實行，一些比較困難，所以大家習慣性的會割裂敏捷實踐的關聯(lián)，孤立地實踐少數(shù)易于實現(xiàn)的敏捷實踐。敏捷開發(fā)之所以可以替代以往傳統(tǒng)開發(fā)模式，是因為一組（系列）的開發(fā)實踐來共同代替以往開發(fā)模式。孤立的引入少數(shù)實踐，通常不能給團隊成員感覺有大的改進，從而也放棄對敏捷開發(fā)的信心。例如Standup Meeting（站立會議）這是一個比較容易的實踐，但是如果沒有背后的需求轉化為比較容易衡量的Storybase，沒有BA、QA等共同參與基于Storybase去溝通，沒有OfflineofMeeting更多的面對面溝通交流，沒有大家彼此知道對方的工作內容（CodeOwnership），那么可以設想這種Standup meeting和以往的傳統(tǒng)的開發(fā)模式，Leader布置任務檢查任務進度沒有任何區(qū)別。再如簡單設計實踐，如果沒有背后的結對編程、重構等實踐，必然導致比較混亂的代碼，很難維護的架構，難于擴展，重復實現(xiàn)類似功能等弊端。再如持續(xù)集成（CI），即使這是公認敏捷軟件領域內相對沒有爭議的一個實踐，但是如果沒有與TDD結合，沒有與持續(xù)重構，沒有與小的Story，快速頻繁Deliver等實踐結合在一起，并且堅持保持CI的健康，也會讓團隊成員覺得CI效果不如宣傳，從而對敏捷實踐等產生質疑。8
環(huán)評公示相關推薦
鄂ICP備17016276號-1