項目問題討論課件

敏捷開發(fā)

——分享交流本次介紹的目標21問題思考

技術債務

scrum上路3項目初期制定一系列計劃，要求在一定時間范圍內完成計劃的功能，而事實往往是項目交付周期延期問題思考-交付延期計劃趕不上變化缺乏與客戶一定的溝通反饋，交付產(chǎn)品的時間階段比較長，客戶看到系統(tǒng)后，又新增需求或變更需求疏遠。太多的會議等煩雜事情要處理，導致整個項目實際的工作脫節(jié)太理想化。開始計劃時就要求一定完成哪些功能開發(fā)人員緊密的開發(fā)完成一個項目后，發(fā)現(xiàn)沒有獲取更多的學習機會和技能問題思考-個人成長沒有更多的參與至項目中缺少主動性、參與性，相互溝通較少混亂。沒有任何時間變得有條理，沒有時間學習新的知識，因為一直都在忙這忙那學習。缺乏自我學習，沒有自我管理的升華，團隊內缺少技能培訓、知識共享項目中經(jīng)常出現(xiàn)的問題不是大問題，而是無數(shù)的小問題。有時這些只是一些為了方便而使用的捷徑（開發(fā)時添加硬編碼、設定魔鬼數(shù)字等），有時開發(fā)人員僅僅是不熟悉這中語言，有時代碼跟灌木叢一樣凌亂，需要大幅度的修整。所有這些都屬于“技術債務”。如果我們沒有很好地管理并設法降低這些“技術債務”，那么，程序編寫和維護的代價最終將會超過它對客戶的價值。開發(fā)團隊拖延債務的時間越長，所積累的問題就會越多(會額外增加很多工作)，付出的成本也就越高。另外，這還增加了實際的財務支出：開發(fā)團隊處理技術債務所花費的時間，可以用在對團隊有價值的其它工作上。同時，這些難讀的代碼引起的技術債務也讓我們難以找到軟件的缺陷。再且，理解代碼所損失的時間還可以用來做其它更有價值的事情呢。技術債務是個累贅：它會扼殺生產(chǎn)力，使維護工作變得麻煩、困難甚至在某些情況下無法實施。技術債務會逐漸使整個團隊的吞吐量越來越少。什么是“技術債務”？債務清償-更改成本曲線“是否該清償技術債務”這樣的問題，答案當然是肯定的。技術債務會逐漸減慢前進的步伐，因而阻礙實現(xiàn)目標。有一種非常著名的更改成本曲線，其中顯示了100%質量測試驅動方法與“懷揣膠帶邊漏邊補的冒進方法”之間的區(qū)別簡單易行的高質量設計可能初始成本較高，但產(chǎn)生的技術債務較少，因而隨著時間的推移，對代碼進行后續(xù)添加或修改的成本相對較低。在質量曲線（藍色）上，可以看到初始成本較高，但長期的成本是可預測的。“冒進”曲線（紅色）的進入成本較低，但后期開發(fā)、維護以及產(chǎn)品和代碼的總體擁有成本都會越來越高。讓開發(fā)人員接受語言方面的基本培訓并教授他們面向對象的原理，從而把他們的理解力提升至入門階段解決技術債務讓團隊成員、管理人員知道解決當前的這些問題都是需要花費時間、精力、代價提供一些培訓，包括代碼的壞味道，重構，單元測試和測試驅動開發(fā)等在工作的時候，給予空余時間去研究和練習技能使用工具（靜態(tài)分析，單元測試，持續(xù)集成，自動化可接受性測試）來幫助團隊發(fā)現(xiàn)、減少和衡量他們的技術債務量解決技術債務建立一些基礎的開發(fā)規(guī)范，從設計、編碼、測試等定期舉行一些關于技術方面的學習型會議。利用這些會議來促進開發(fā)成員之間的討論維護關于技術債務的備忘錄–任何時候，如果開發(fā)中發(fā)現(xiàn)一些無法立即應付的技術債務時，就需要填寫一份技術