本文轉自我原博客:我的原博客地址,原博客已不再更新.
讓用戶做決定
在設計方面,做決定的時候必須有開發者參與.
在一個項目中,開發者不應該做所有的決定,特別是業務方面的決定.
決定什麼不該決定.
讓客戶做決定.開發者,經理或者業務分析師不應該做業務方面的決定.
業務應用需要開發者和業務負責人互相配合來開發.
平衡的藝術
記錄客戶做出的決定.
不要用過於具體和沒有價值的問題打擾繁忙的業務人員.
不要假設具體的問題不會影響業務人員的業務.
如果業務負責人回答”我不知道”,這也是一個稱心如意的答案.
讓設計指導而不是操縱開發
設計是軟件開發過程不可缺少的步驟.
開發之前畫關鍵工作圖是必不可少的,在做設計時你需要花時間去考慮各種不同選擇的缺陷和溢出,以及如何權衡.然後下一步才考慮開始編碼.
嚴格的需求-設計-代碼-測試開發流程源於理想化的瀑布式開發方法,它導致在前面進行了過度的設計.
設計可以分爲兩層:戰略和戰術.
1. 前期的設計屬於戰略,通常只有在麼有深入理解需求的時候需要這樣設計.
2. 戰術設計重點是集中在單個的方法或數據類型上.這時更合適討論如何設計類的職責.
CRC(類-職責-協作)卡片的設計方法就是用來做這個事情的.
* 類名
* 職責:它應該做什麼?
* 協作者:要完成工作它需要與其他的什麼對象一起工作?
什麼是好的設計?
如果需求有了小變化,它仍能容易去實現,那麼它就是好的設計.
好的設計應該是正確的而不是精確的.
平衡的藝術
- 不要在前期做大量的設計,並不是說不要設計.
- 計時初始的設計到後期不在管用,你仍需設計.
- 白板,草圖,便利貼都是非常好的設計工具.
合理地使用技術
根據需要選擇技術.
在考慮使用新技術之前,先要把你需要解決的問題找出來.找到了需要解決的問題,接下來就要考慮:
1. 這個技術框架真能解決這個問題嗎?
2. 你將會被他拴住嗎?
3. 維護成本是多少?
不要開發你能容易下載到的東西
寫的代碼越少,需要維護的東西就越少!
新技術就應該像是新工具,可以幫助你更好地工作,它自己不應該成爲你的工作.
平衡的藝術
- 也許在項目中真正評估技術方案還爲時太早.
- 每一門技術都會有有點和缺點.
保持可以發佈
已經提交的代碼應該隨時可以行動.
任何時候只要你沒有準備好,就是敵人進攻你最佳的時機.
在團隊工作中,修改一些東西的時候必須很謹慎.
如何防止你提交的代碼破壞系統的代碼?
1. 在本地測試運行.
2. 檢出最新的代碼
3. 提交代碼
保持你的項目時刻可以發佈.保證你的系統隨時可以編譯,運行,測試並立即部署.
平衡的藝術
1. 有時候,做一些大的改動後,你無法花費太多的時間和精力去保證系統一直可以發佈.但是這只是例外,不能養成習慣.
2. 如果你不得不讓系統長期不可發佈,那就做一個分支版本,你可以繼續進行自己的試驗.如果不行,還可以撤銷,從頭再來.
3. 千萬不能讓系統既不可以發佈,有不可以插銷.
提早集成,頻繁集成
在產品的開發過程中,集成是一個主要的風險區域.
獨立開發和早期集成之間是具有張力的.
當你獨立開發時,會發現開發速度更快,生產效率更高,你可以有效地解決出現的問題.
但並不意味着你避免或者延遲集成.一般需要每天集成幾次,最好不要2~3天集成一次.
絕不要做大爆發式的集成.
平衡的藝術
1. 成功的集成就意味着所有的單元測試不停地通過.
2. 每天要和團隊其他成員一起集成好幾次.
3. 如果你集成的不頻繁,也許救會發現整天在解決代碼集成帶來的問題,而不是專心寫代碼.
4. 獨立開發很好,但是不能獨立開發太久,一旦你有了經驗就要快速地開始集成.
提早實現自動化部署
如果現在你還是在手工幫助質量保證人員安裝應用,花些時間,考慮如何將安裝過程自動化.
質量保證人員應該測試部署過程
在項目一開始就應該實現自動化部署.
平衡的藝術
- 一般產品在安裝的時候,都需要有相應的軟硬件環境.這些環境的不同可能會導致很多問題,所以檢查依賴關係,也是安裝過程的一部分.
- 在沒有徵得用戶的統一之前,安裝程序絕不能刪除用戶的數據.
- 部署一個緊急修復的bug應該很簡單,特別是在生產服務器的環境中.
- 用戶應該可以安全且完整地卸載安裝程序.
- 如果維護安裝腳本變得很困難,那可能是一個早起警告.
使用演示獲得頻繁的反饋
需求就像流動的油墨.
你無法凍結需求,正如你無法凍結市場,競爭,知識,進化或者成長一樣.
沒有人的思想和觀點可以及時凍結,特別是項目的客戶.
不管是什麼事情,我們都能做好,不過是以緩慢而逐步的方式.
軟件開發的成功就在於最後你離客戶的期望有多遠.
應該定期的每隔一段時間,與客戶進行演示反饋.
如果你能頻繁地和用戶協商,根據他們的反饋,每個人都可以從中收益.
不一致的術語是導致需求誤解的一個主要原因.所以需要維護一個項目術語表.
項目開發應該是清晰可見的開發.
平衡的藝術
演示是用來讓客戶提出反饋,有助於駕馭項目的方向.
使用段迭代,增量發佈
統一過程和敏捷開發都使用迭代和增量開發.
迭代開發是你在小且重複的週期裏完成各種開發任務.
對付大項目,最理想的辦法就是小步前進,這也是敏捷開發的核心.
大部分用戶都是希望現在就有一個夠用的軟件,而不是在一年之後得到一個超級軟件.
詢問用戶哪些是產品的可用且不可少的核心功能.
不要爲所有可能需要華麗功能而分心,不要沉迷於你的想象,而去做那些華而不實的界面.
儘快發佈你的應用,遲了也許它就沒有作用了.
使用段迭代和增量開發,可以讓開發者更加專注於自己的工作.
段迭代讓人感覺非常專注且具效率
平衡的藝術
- 如果每個迭代的時間都不夠用,要麼任務太大,要麼因爲迭代時間太短,把握好自己的開發節奏.
- 如果發佈的功能背離了用戶的需求,多半是因爲迭代的週期太長了.
- 增量的發佈必須是可用的,並且能爲用戶提供價值.
固定的價格就意味着背叛承諾
軟件項目天生就是變化無常的,不可能重複.
開發項目時如何與客戶交流?
1. 主動提議先構建系統最小,小的和有用的部分.
2. 第一個迭代結束時客戶有兩個選擇:可以選擇一系列新的功能,繼承進入下一個迭代.或者可以取消合同.
3. 如果他們選擇繼續前進,那麼這時候,應該就能很好地預測下一個迭代工作.
基於真實工作的評估.
平衡的藝術
1. 如果你對答案不滿意,那麼看看你是否可以改變問題.
2. 如果你在完成第一個迭代開發之前,拒絕做任何評估,也許你會失去這個合同.
3. 敏捷不是意味着開始編碼,我們最終會知道合適可以完成.你需要根據當前的知識和猜想,做一個大致的評估.
4. 如果你別無選擇,你不得不提供一個固定的價格,那麼你需要學到真正好的評估.
5. 也許你會考慮在合同中確定每一個迭代的固定的價格,但迭代的數量是可以商量的,它可以根據當前的工作狀況進行調整.