高效程序員的45個習慣 敏捷開發修煉之道 讀書筆記 第四章 交付用戶想要的軟件

讓客戶作決定

開發者及項目經理能作的一個最重要的決定就是：判斷哪些是本身決定不了的，應該讓企業主作決定。

當你和客戶討論問題的時候，準備好幾種可選擇的方案。從業務的角度介紹每種方案的優缺點，以及潛在的成本和利益，

並和他們討論每一個選擇對時間和預算的影響，以及如何權衡，記錄客戶作出的決定，並註明緣由。

 

讓設計指導而不是操縱開發

好的設計是一張地圖，它也會進化。設計指引你向正確的方向前進，她不是殖民地，它不該該表示具體的路線，你不要被設計操縱。

CRC卡片的設計方法

類名：。

職責：它應該作什麼？

協做者：要完成工做他要與其餘什麼對象一塊兒工做？

 

合理地使用技術

根據須要選擇技術 首先決定什麼是你須要的，接着爲這些具體的問題評估使用技術，對任何要使用的技術，多問一些挑剔的問題，並真實地作出回答。

引入新技術時候考慮：

這個技術框架真能解決這個問題嗎？

你將會被它拴住嗎？

維護成本是多少？

 

保持能夠發佈，提前集成，頻繁集成。

主要講的是版本控制問題，公司分一條master分支用於不斷迭代開發而develop分支用於版本發佈

但發現一些緊急的bug直接在發佈版本分支修改，而後再master修改

一些版本升級的需求則是基於master創建問題分支，後集成

代碼集成是主要的風險來源。想要規避這個風險，只有提前集成，持續而有規律地進行集成，

集成拖得太晚，可能因爲分支以前各樣的依賴關係，會致使集成順序形成集成失敗，

 

提前實現自動化部署

一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不一樣的機器上用不一樣的配置文件測試依賴的問題。質量保證人員要測試應用同樣測試部署。

這些工做都應該是無形的。系統的安裝或者部署應該簡單、可靠及可重複。一切都很天然。

 

使用演示得到頻繁反饋

清晰可見的開發。在開發的時候，要保持應用可見（並且客戶心中也要了解）。每隔一週或者兩週，邀請全部的客戶，給他們演示最新完成的功能，積極得到他們的反饋。

跟蹤問題不少反饋--修正、建議、變動要求、功能加強、bug修復等，要注意的信息不少，建議有個一跟蹤系統記錄這些日誌，或使用excel上傳到git。

 

使用短迭代，增量發佈

增量發佈，發佈帶有最小卻可用功能塊的產品。每一個增量開發中，使用1~4周左右迭代週期。短迭代讓人感受很是專一且具效率。你能看到一個實際而且確切的目標。嚴格的最終期限迫使你作出一些艱難的決策，沒有遺留下長期懸而未決的問題。

 

固定的價格就意味着背叛承諾

讓客團隊和客戶一塊兒，真實地在當前項目中工做，作具體實際的評估，由客戶控制他們要的功能和預算。

如何估算項目花費以及時間又是另外一門學問了

1.提議想構建系統demo（作出最主要功能部分），完成第一次交付應該很少於6~8周，向客戶解釋，讓用戶真正使用

2.客戶能夠選擇一系列新的功能，或者能夠取消合同，僅需字符第一個迭代的幾周費用

3.接下來的迭代就比較好控制了