《靈活疊代開發管理者指南》讀書筆記

[align=center][img]http://img3.douban.com/lpic/s2170207.jpg[/img][/align]

這是一本關于疊代開發的各個流派的一個總結式讀本. 可以讓你在最短的時間内了解各個靈活開發方式是如何實作疊代開發的.

==============我是讀書筆記的分割線===================

拒絕固定需求文檔的理由:

客戶或使用者不能明确知道他們要什麼

他們很難陳述他們的需求和知識

他們想要的許多細節隻能在開發過程中逐漸展現

細節對于他們來說過于複雜

當他們看到産品的開發, 會改變他們的初衷

外部的(競争)壓力導緻需求的變更或者增強

靈活需求:從我們的已經産生的進階需求清單中, 挑選出20%最具有架構意義, 最具有風險以及最具有價值的條目

由于存在比較高的變化率, 這成為靈活與疊代開發的動機的核心

短小的疊代導緻對完成, 能力與結束有一種快捷和反複的感覺. 這些心理學因素對于個體成就感和建構團隊信心至關重要, 這同樣也建構了團隊中客戶信心--他們看到早期的可視化的過程, 朝着他們關心的方向發展.

研究表明在提高生産率方面, 時間箱帶來好處的一個原因就是專注.

心理學認為結束日期為三周之後, 比在三個月之後設立的可視裡程碑, 專注的效果更好

通過在為期兩周的時間箱疊代, 團隊可承擔可管理的複雜度, 做他們力所能及的工作, 同時也可以在可能突破最後期限内的情形下, 他們有能力縮小工作範圍.

瀑布型的方法隻适應于非常直接, 缺少變化的項目.

瀑布模型的開發方式, 将高風險和困難的元素推遲到項目最後, 而對于疊代開發方式來說, 則是通過風險驅動的疊代, 使最困難和最具風險的元素盡早地出現并解決.

scrum的一個關鍵理念是強調經驗型過程, 而不是規定性的過程.

系統開發有着非常巨大的不确定性和複雜性. 以至于它必須通過經驗型的過程控制模式來管理.

晨會的第三個問題: 是什麼阻礙了目标的實作?

增加的兩個問題:

有沒有任務添加到Sprint待辦事宜中?

相對于團隊中的其他成員, 你是否學到了一些東西或者做出了一些新的決定(技術, 需求...)

晨會最好在一塊白闆前召開, 白闆用于開會的記錄報告的所有任務和障礙

scrum的價值觀:

承諾: 團隊承諾實作規定的疊代目标

專注: 團隊需要排除幹擾, 專注于規定的疊代任務

公開: 公開産品待辦事宜, 使工作以及優先級都可以被看到

尊重: 強調整個團隊的責任, 而不是尋找替罪羊

勇氣: 管理者應該有勇氣制定計劃并進行相應的指導.

XP

xp的獨到之處在于, 除了代碼和測試, 它不需要其他詳細工件, 但也不排斥其他工件

xp不是黑客式的邊寫邊改, 而是摒棄了大部分的文檔開銷, 更強調代碼生産力和口頭溝通.

極限程式設計中的"極限"表示的是要将軟體開發中的優點演繹到極緻, 也就是說如果是好的實踐, 就應該最大限度的發揮它們的作用.

測試是好的實踐, 于是所有代碼編寫單元測試

代碼審查是好的實踐, 那麼實時的進行代碼審查, 并且在整個開發過程中通過結對來進行代碼審查.

對所有開發人員的代碼進行頻繁的內建是一項好的實踐, 那麼用一台專門的機器, 進行自動, 7*24不停的進行持續內建.

短期疊代是好的實踐...

客戶更多的參與是好的實踐...

溝通是好的實踐...

XP鼓勵用最簡單的方式記錄需求

XP故事不是用例或者場景, 它們通常描述特征

XP中口頭溝通是首選, 故事卡的目的不在于細化故事, 而是略記一個大概, 作為其他文檔的參考, 一般情況下将卡片看成溝通提示.

避免文檔可以通過現場客戶來進行彌補, 但并不反對文檔, 隻是将其看成一種開銷, 希望通過更多的時間進行程式設計

編寫測試的實踐将影響構思, 澄清和簡化設計.

TDD使開發者具有成就感: 我編寫測試, 然後我取得測試的成功, 這種滿足感驅使着實踐.

當疊代無法在時間箱内完成, 延長周期是一種錯誤的認識, 更好的做法是取消這次疊代, 或者簡化一些目标, 并分析這次失敗的原因是什麼.