敏捷開發(fā)的常見誤區(qū)-預覽頁
【正文】 任他們能夠完成工作。責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度。12) 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。要實用而不是要機械式的規(guī)范。其實，早期的Scrum項目就已經有在500多人的大型項目中成功實施的案例。在Scrum中，就有Scrum Scaling，通過把一個大型項目團隊合理分解為多個小型的Scrum團隊，每個團隊都負責一個相對獨立的模塊或者功能，再配合其他的敏捷實踐，比如持續(xù)集成，Scrum of Scrums等，加強團隊之間的協(xié)作，從而確保項目的成功。實際應用中，既有流程相當簡單的經典Scrum過程，也有極為冗繁、不亞于CMMI的RUP，根據(jù)應用場景不一樣，項目組應該使用最適合的流程。符合敏捷開發(fā)思想的流程往往主張在一個穩(wěn)定的基礎之上迭代完成各種功能。8. 誤區(qū)：敏捷是徹底革命的。實施敏捷應該以現(xiàn)有的軟件過程為基礎，從敏捷宣言和原則出發(fā)，利用敏捷的方法來改善過程?！ 撉宄臋n的本質是把知識顯性化。 文檔不是目的，有效溝通才是目的。例如需求文檔（或者功能文檔可以含有版本信息，業(yè)務流程文檔，互通操作文檔），無論具體形式如何，需要清晰地給出你的應用針對什么，提供什么，解決什么。例如開發(fā)文檔，不一定要什么概要設計、詳細設計這類學院派的東東，但是你需要有文檔能夠清晰描述開發(fā)對象的架構，模塊劃分，client和server的交互流程，以及關鍵的核心技術，例如，如何避免client和server中過多連接造成的server壓力，為何采用長連接tcp而非upd（反之亦然），如何制定心跳，是否需要通過使用底層的socket進行特定優(yōu)化等等。現(xiàn)在工作的流動性很大，沒有文檔，當中一兩個開發(fā)人員離職，如何后續(xù)處理。10. 誤區(qū)：敏捷是自由的，無約束的。作為管理者，有一個職責，就是引導團隊成員用自己積極的一面去壓制消極的一面，不能放任團隊中出現(xiàn)搭便車的現(xiàn)象，否則將打擊整個團隊的士氣。 12. 誤區(qū)：傳統(tǒng)開發(fā)能隨時轉變成敏捷開發(fā)敏捷開發(fā)過于誘人，很容易讓深受傳統(tǒng)軟件開發(fā)思想折磨的開發(fā)人員感覺敏捷開發(fā)就是靈丹妙藥。舉例來說。13. 誤區(qū)：敏捷是CMM的反義詞 CMM只是一種衡量軟件成熟度的標準，并非過程，和敏捷不是一類概念。如果把結對編程、daily scrum當做是敏捷開發(fā)的表現(xiàn)，那更是本末倒置，可悲的是，不少人還真是這么認為的。同時也給客戶一個感受和思考的機會，因為對于大多數(shù)客戶而言，目標是明確的（不排除有些客戶目標也不明確），但是具體怎么做，開始時是沒有想法的，只有看到具體的東西的時候，才知道“噢，原來可以這樣，那我想把這里調整一下”。17. 誤區(qū)：版本更新很快，甚至每天都有新版本。內測版本或試用版本也是經過開發(fā)人員驗證和測試后放出來，通過實際使用情況，收集用戶對功能和操作中的意見，并對實際使用中測試案例無法覆蓋的可能異常情況進行驗證。將版本更新速度視為敏捷開發(fā)，是完全錯誤的。但這個版本，不是小修小補的小版本，而是有新功能，新UI，新互動方式，在用戶體驗上有新的感受。但是實際上團隊成員的素質參差不齊，如果只有簡單設計、立即編碼，而沒有后續(xù)的持續(xù)重構等實踐，將導致設計混亂不一致，尤其是對老系統(tǒng)的功能升級，如果對原有系統(tǒng)的影響分析不夠，弱化了分析設計，將導致很多工作在后期頻繁變更，使得團隊的挫折感增強，產生較多的重復工作和浪費。（1）需求質量的審核，仍然需要改進，需求方向性的錯誤將導致后續(xù)一系列的工作浪費，所以團隊內部應該設定里程碑和review標準，從而確?；镜男枨筚|量。有些變更通過更好的Impact分析和設計應該也可以避免。孤立的引入少數(shù)實踐，通常不能給團隊成員感覺有大的改進，從而也放棄對敏捷開發(fā)的信心。8
環(huán)評公示相關推薦
鄂ICP備17016276號-1