硝煙中的Scrum和XP

用戶評(píng)論 (總計(jì)30條)

•   　　半年前同事極力推薦了這本書而且謝了一篇對(duì)他來說茅塞頓開的讀后感。春節(jié)期間看完了這本僅僅有著100多頁(yè)的書，這也是今年看完的第一本書?？赐杲o我的感覺就是“這是一個(gè)令我不是完全明白的好方法”。書中很多觀點(diǎn)和方法對(duì)于產(chǎn)品開發(fā)都是很好的，不過正如作者所說，這種方法目前也是還在不斷嘗試和改進(jìn)中，至于是不是最好的方法，當(dāng)然取決于各個(gè)公司的“國(guó)情”。
  　　
  　　依稀記得2011年公司曾經(jīng)采用過類似的產(chǎn)品開發(fā)模式：評(píng)估項(xiàng)目工作量、確定開發(fā)進(jìn)度和交付日期，采用白板更新進(jìn)度等等。后來因?yàn)楦鞣N執(zhí)行上的困難和弊端不了了之了?？赐赀@本書結(jié)合公司之前的失敗經(jīng)驗(yàn)，我做一些關(guān)于產(chǎn)品開發(fā)管理和敏捷開發(fā)的個(gè)人認(rèn)識(shí)和總結(jié)，希望能與大家一起探討好的開發(fā)進(jìn)度和管理模式。
  　　
  　　1、產(chǎn)品開發(fā)/項(xiàng)目開發(fā)就像個(gè)人的職業(yè)規(guī)劃和工作計(jì)劃一樣，必須有長(zhǎng)線和短線。長(zhǎng)線規(guī)劃公司產(chǎn)品的未來發(fā)展及主要節(jié)點(diǎn)；短線要具體分解每一步具體要執(zhí)行的步驟及模塊，甚至要細(xì)分到每一周，每一天的工作安排。只有讓所有人明白了項(xiàng)目的目標(biāo)和需要做的事情，大家才能擰成一股繩一起去努力。我所理解的每一個(gè)sprint（我理解為“發(fā)布周期”）流程為：
  　　
  　　理清工作思路→確定工作量（全體會(huì)議）→確定交付日期（全體會(huì)議）→分配工作內(nèi)容（技術(shù)團(tuán)隊(duì)內(nèi)部會(huì)議）→公布工作量及目標(biāo)（對(duì)外公布）→及時(shí)更新工作進(jìn)度（對(duì)外公布）
  　　
  　　這樣做的好處：
  　　
  　　可以讓團(tuán)隊(duì)都清楚大家接下來一段時(shí)間的目標(biāo)是什么，擰成一股繩。
  　　
  　　可以讓每個(gè)人都清楚別人每天都在干什么，這樣才會(huì)在內(nèi)部形成競(jìng)爭(zhēng)力。
  　　
  　　可以讓公司的領(lǐng)導(dǎo)及其他部門都知道團(tuán)隊(duì)都在干什么并且知道每天都完成了哪些內(nèi)容減少了不必要的談話，會(huì)議和質(zhì)疑。
  　　
  　　對(duì)項(xiàng)目的把控性增強(qiáng)了，知道什么時(shí)候需要催一催進(jìn)度，什么時(shí)候可以讓大家稍微放松。
  　　
  　　難點(diǎn)：如何準(zhǔn)確預(yù)估（評(píng)估）工作量，如何避免過多預(yù)估工作量導(dǎo)致產(chǎn)品失去競(jìng)爭(zhēng)力？
  　　
  　　2、合理使用“燃盡圖”。它能夠幫助團(tuán)隊(duì)及時(shí)判斷項(xiàng)目進(jìn)展是否在計(jì)劃之中，避免產(chǎn)品開發(fā)進(jìn)度過快或者過慢。
  　　
  　　3、多做有用的事。去掉花里胡哨的東西。也不要把時(shí)間花在會(huì)議PPT的美化上，傳達(dá)出報(bào)表大的信息即可。
  　　
  　　4、下一個(gè)sprint中如何做得更好，需要總結(jié)上一個(gè)sprint中存在的問題和需要改進(jìn)的地方。
  　　
  　　5、制定一個(gè)大的產(chǎn)品發(fā)布規(guī)劃大plan（plan1,plan2···）包括大致的發(fā)布日期。這中間牽扯到版本發(fā)布計(jì)劃，除了正在進(jìn)行的sprint需要確定精確的發(fā)布日期和發(fā)布內(nèi)容外，后面的都可以根據(jù)實(shí)際需求的變更做出靈活調(diào)整。
  　　
  　　6、上一個(gè)sprint和下一個(gè)sprint之間設(shè)立一個(gè)“緩沖日”，用于給團(tuán)隊(duì)成員調(diào)整狀態(tài)。
  　　
  　　7、我的疑惑：
  　　
  　　拆分功能點(diǎn)（模塊）的方法。
  　　
  　　測(cè)試bug的修復(fù)安排是否占用下一個(gè)sprint時(shí)間，如果占用，如何來保證下一個(gè)sprint進(jìn)度？
  　　
  　　
  　　
  　　有一點(diǎn)是我在讀書過程中發(fā)現(xiàn)的：書中一些自己經(jīng)歷過的事情讀起來會(huì)很有味道，也很能揣測(cè)一些當(dāng)時(shí)存在的不足和經(jīng)驗(yàn)。而還有一些自己不是很熟悉的部分則比較拗口難懂，一掃而過有一個(gè)印象即可，隨著經(jīng)歷也會(huì)慢慢深入并得到啟發(fā)。
•   　　正如本書的副標(biāo)題所說的那樣，“我們?nèi)绾螌?shí)施Scrum”，該書能夠帶你走進(jìn)Scrum的世界，告訴你每個(gè)Scrum對(duì)應(yīng)的事件具體該怎么實(shí)施，比如怎么開sprint planning， 怎么開daily scrum等。同時(shí)，它還給出了一些在實(shí)施過程中遇到的問題以及解決方案。即使你從沒實(shí)施過Scrum，看完此書，就好像你已經(jīng)實(shí)施了一次完成的Scrum流程一樣。
•   　　在經(jīng)歷了一年多敏捷實(shí)踐，看了幾本Scrum理論書籍后（基本都沒有看完），帶了一堆疑問和困惑打開這本印刷精美的小書，頓時(shí)有一種豁然開朗的感覺。
  　　好長(zhǎng)時(shí)間沒有看完一本書的沖動(dòng)了，每一章看過后都有不少收獲，里面總能找到當(dāng)前項(xiàng)目Scrum實(shí)踐中遇到的問題和解決方法。
  　　另外中文版翻譯總體質(zhì)量也不錯(cuò)，值得推薦！
•   　　#阿一讀書# 《硝煙中的Scrum和XP》：把它放在《Scrum要素》之后閱讀絕對(duì)是個(gè)明智的選擇：兩書一本重理論一本重實(shí)踐，一本是框架一本是方法，一本是授道一本解惑。這本書其實(shí)兩年前就看過，只是那時(shí)候太稚嫩，只看到了最膚淺的東西……
•   　　這本書是我所看的Scrum方面圖書的一本。
  　　作者講到了很多Scrum實(shí)踐中的小細(xì)節(jié)，比如在Sprint計(jì)劃會(huì)議的時(shí)候有些人不知道該干什么如何處理等等。其實(shí)給我印象最深刻的是對(duì)生產(chǎn)率的相關(guān)運(yùn)用。比如生產(chǎn)率結(jié)合sprint來預(yù)測(cè)項(xiàng)目進(jìn)展。
•   　　 沒有什么廢話，沒有什么華麗語(yǔ)言的修飾，一切都是大白話和大實(shí)話。但是這一切都是出自真正的實(shí)戰(zhàn)經(jīng)驗(yàn)和總結(jié)。
  　　 剛開始看的時(shí)候不以為然，但是隨著自己實(shí)施Scrum之后，發(fā)現(xiàn)里面的很多經(jīng)驗(yàn)可以直接照搬過來，而且很多我犯的錯(cuò)誤，書中都已經(jīng)提示了，只是我沒有注意而已。
  　　 如果從零開始Scrum的話，看看不錯(cuò)，如果沒有正經(jīng)的看過Scrum的書，這本書真的也不錯(cuò)。
  　　
•   　　 這本書得到很高的評(píng)價(jià)，但是我用了一天時(shí)間看完后，獲得點(diǎn)子有三個(gè)：
  　　 1、可以讓兩個(gè)SCRM團(tuán)隊(duì)交換SM進(jìn)行回顧會(huì)；
  　　 2、要有迭代計(jì)劃，還要有發(fā)布計(jì)劃；
  　　 3、幾個(gè)SCRUM迭代后，讓團(tuán)隊(duì)休整一天是很好的行軍方法；
  　　 不是我太挑剔，而是作者這本書寫的太早了，這本書又寫的太精簡(jiǎn)，像一個(gè)微型手冊(cè)，給新新手用吧。
•   　　 我手頭的這本《硝煙中的Scrum和XP》是互動(dòng)出版社贈(zèng)送的，在這里謝謝"圖靈教育－曉敏"和互動(dòng)出版社。
  　　 在讀這本書之前，我對(duì)敏捷開發(fā)基本上一無所知，雖說也聽過結(jié)對(duì)編程，極限編程等概念，但沒深究過。
  　　 我下面主要會(huì)說到2件事：
  　　 一，簡(jiǎn)要說明我所在公司所用的軟件開發(fā)方法（估計(jì)也是大多是公司采用的）
  　　 二，敏捷開發(fā)中有哪些值得借鑒的（很多話可能摘自本書原文）
  　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  　　
  　　 一，
  　　 我所在的部門所用的軟件開發(fā)有點(diǎn)像“瀑布模型”，從產(chǎn)品的spec確定（主要由PM負(fù)責(zé)）--->需求分析（主要由項(xiàng)目經(jīng)理以及RD參與）--->軟件設(shè)計(jì)（項(xiàng)目經(jīng)理和RD--->程序編碼（RD負(fù)責(zé)）--->測(cè)試（測(cè)試人員和RD負(fù)責(zé)）--->運(yùn)行維護(hù)（RD負(fù)責(zé)）。期間可能為了方便維護(hù)產(chǎn)生大量文檔：PS（規(guī)格說明書），Mockup（產(chǎn)品雛形）， ES（需求說明書），DS（設(shè)計(jì)說明書），TP（測(cè)試計(jì)劃）等等。確實(shí)很耗費(fèi)時(shí)間，最耗費(fèi)時(shí)間的2個(gè)點(diǎn)是：
  　　 1，ES這點(diǎn)（PS是由PM確定，所以我不知道實(shí)際情況），常常到編碼完成了ES還會(huì)改變，PM有時(shí)自己都不知道需求，一天變一個(gè)說法，RD和PM有時(shí)交流有問題，大部分PM不會(huì)寫code，有些問題跟他們說不清楚，當(dāng)然RD有時(shí)也亂七八糟的。
  　　 2，測(cè)試階段，我們的方法是先內(nèi)側(cè)，然后交給專門的測(cè)試人員，把所有feature測(cè)一遍，回歸測(cè)試等，如果時(shí)間比較緊的話，RD沒很多時(shí)間做單元測(cè)試，代碼質(zhì)量有待商榷，而且RD一般都不喜歡測(cè)試自己代碼，現(xiàn)在測(cè)試自動(dòng)化應(yīng)用也沒那么廣泛，很多還是要手工測(cè)試，這又取決于測(cè)試人員的效率和素質(zhì)，測(cè)試人員（QA）有時(shí)和RD溝通有時(shí)會(huì)有困難，尤其是異地！產(chǎn)生bug后，有些bug還需要跟PM確認(rèn)，甚至?xí)绊慐S，RD修復(fù)然后再給QA測(cè)試，總之很耗費(fèi)時(shí)間。
  　　 如果一款產(chǎn)品從Ps制定到交付給客戶需要6個(gè)月，真正用于編碼的時(shí)間可能只有1.5月，不順的話，測(cè)試和修復(fù)bug階段可能要占據(jù)接近2月。
  　　 效率是比較偏低的。當(dāng)然這樣出來的產(chǎn)品應(yīng)該比較穩(wěn)，但卻是耗費(fèi)了很多人力和時(shí)間。那么，我們可以從敏捷開發(fā)中學(xué)到什么？
  　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  　　
  　　 二，
  　　 我對(duì)scrum和xp了解甚少，以后會(huì)持續(xù)關(guān)注，這我的水平也不適合闡述scrum和xp的種種。
  　　 這兒我主要提2個(gè)東西，backlog和sprint。
  　　
  　　 backlog就像需求分析文檔，不過它是以條目的形式組織在一起，而不是分散在文檔中，用excel等工具展示出來的話比較清晰。
  　　 有幾點(diǎn)值得借鑒的是，它有一個(gè)字段是important，標(biāo)識(shí)這個(gè)item的重要性。還有一個(gè)字段標(biāo)識(shí)，這個(gè)item（比如添加一個(gè)用戶）會(huì)花多少時(shí)間完成。還有個(gè)字段講如何做演示（這里就考慮到測(cè)試了）。而且它的字段是彈性的，所以可以加一些其他標(biāo)識(shí)字段，這樣一來即便新人接手也會(huì)一目了然，總比看ps和Es文檔來得快?。?br /> 　　
  　　 Sprint就感覺像一個(gè)project（或者project階段）從開始到結(jié)束的過程。
  　　 制定sprint計(jì)劃，這里涉及到resource和時(shí)間的分配以及確定產(chǎn)品的哪些feature需要完成還有很多細(xì)節(jié)，我覺得站著開會(huì)是個(gè)不錯(cuò)idea。
  　　然后把討論后的規(guī)劃貼出來，讓大家都能看見，這樣目標(biāo)也比較明確，用小黑板和墻是個(gè)不錯(cuò)的建議。根據(jù)項(xiàng)目的進(jìn)度更新小白板和墻是個(gè)更不錯(cuò)的建議。讓別人知道你們?cè)诟陕?..在小白板上把任務(wù)分解，用一些曲線或者其他幾何形狀標(biāo)識(shí)一些東西，這樣客戶心里也有底：哦，他們?cè)诟陕锔陕?..領(lǐng)導(dǎo)心里也有底，這些家伙沒有混日子的。加入新人也能一目了然得知道你們?cè)诟陕?..自己人也看到進(jìn)度條在動(dòng)或者自己做了些事情。
  　　
  　　 RD之間坐的近，相互充分交流有助于開發(fā)效率的提高，遇見問題也可以立馬問，總之團(tuán)隊(duì)氣氛要活躍，死氣沉沉不是好事。
  　　
  　　 像做銷售一樣，為了讓項(xiàng)目經(jīng)理知道項(xiàng)目進(jìn)展?fàn)顩r，每日例會(huì)是個(gè)不錯(cuò)的建議，而且時(shí)間也短，大家早上來上班就制定計(jì)劃，今天要干嘛干嘛，周圍人也知道，你也偷不了懶，你也不好意思拖進(jìn)度，沒事可以給你找事做。
  　　
  　　 做階段性的產(chǎn)品演示可以讓rd感覺自己在完成某種東西，至少不是虛度年華！??！
  　　
  　　 集體進(jìn)行階段性的回顧。
  　　
  　　 多用維基百科(感覺這樣文檔只有一份，而且不會(huì)丟，便于查找，放在server上有時(shí)不方便，而且本地還有多份拷貝）。版本控制系統(tǒng)就不說了。
  　　
  　　 讓員工有時(shí)間思考自己的工作，加入自己的idea或者完成自己的想法(這個(gè)要求太高，不是每個(gè)公司都像google）
  　　
  　　
  　　 發(fā)布產(chǎn)品最好不要延期，同時(shí)要確保質(zhì)量，如果可以放到下一版，那就下一版本吧。
  　　
  　　 測(cè)試是個(gè)難題，測(cè)試是提高代碼質(zhì)量的最可靠方法之一。但測(cè)試需要時(shí)間，所以如何利用工具或者腳本多做自動(dòng)化測(cè)試，如何提高手工測(cè)試效率等等問題都值得探討。
  　　
  　　 結(jié)對(duì)編程不好實(shí)施。
  　　
  　　 提高自己的編碼素質(zhì)，變得更牛更牛！！
  　　
  　　 書中講到的團(tuán)隊(duì)管理這里就不多copy了。
  　　
  　　 總之是本很具參考價(jià)值的書籍。
  　　
  　　
•   　　【第5波贈(zèng)書】贈(zèng)敏捷開發(fā)類圖書25本
  　　
  　　活動(dòng)規(guī)則：
  　　1、推薦本帖子，并回復(fù)說明自己希望得到贈(zèng)書的理由，一句話即可，當(dāng)然長(zhǎng)了也不反對(duì)。
  　　2、獲得贈(zèng)書者須在收到贈(zèng)書的2個(gè)周內(nèi)回饋1篇500字以上的書評(píng)。
  　　3、回復(fù)中位于9樓、99樓、199樓、299樓、399樓者將自動(dòng)獲得贈(zèng)書1冊(cè)，每樓1冊(cè)總共5冊(cè)。
  　　4、剩余20冊(cè)贈(zèng)書，隨機(jī)抽取20名幸運(yùn)者進(jìn)行贈(zèng)送，
  　　
  　　
  　　活動(dòng)地址http://www.douban.com/group/topic/21038601/
  　　
  　　
  　　活動(dòng)時(shí)間：
  　　2011.07.12—2011.08.12日
  　　
  　　贈(zèng)書清單：
  　　1、《用戶故事與敏捷方法》http://product.china-pub.com/196596
  　　2、《Scrum敏捷項(xiàng)目管理實(shí)戰(zhàn) 》http://product.china-pub.com/44689
  　　3、《敏捷軟件開發(fā)：原則、模式與實(shí)踐》http://product.china-pub.com/13569
  　　4、《硝煙中的Scrum和XP——我們?nèi)绾螌?shí)施Scrum 》http://product.china-pub.com/197645
  　　5、《Scrum敏捷軟件開發(fā) 》http://product.china-pub.com/197153
  　　
  　　注：贈(zèng)書為目前這5種，《敏捷項(xiàng)目管理(第2版)》不再參加此贈(zèng)書活動(dòng)。
•   　　作者對(duì)scrum 實(shí)踐中點(diǎn)點(diǎn)滴滴總結(jié)，正中要害。我即將在 團(tuán)隊(duì)中實(shí)施 scrum，這本書給我很多啟示。尤其是對(duì)團(tuán)隊(duì)成員能力的要求，scrum 是一種方法，而不是一個(gè) 對(duì)團(tuán)隊(duì)成員能力要求的標(biāo)準(zhǔn)，或者注解。一個(gè)自我激勵(lì)，自我組織，提高效率的團(tuán)隊(duì) 是一個(gè) 理想的 scrum 狀態(tài)，但這只是終點(diǎn)，并非起點(diǎn)。
  　　
•   　　翻譯的不錯(cuò)， 淺顯易懂， 非常具有實(shí)戰(zhàn)意義。完全是作者親身體會(huì)的總結(jié)。不過感覺scrummaster相關(guān)的東東介紹的太少了。
  　　
  　　====================以下是讀書筆記的分割線===================
  　　
  　　Scrum不是方法學(xué)，它是一個(gè)框架。也就是說Scrum不會(huì)告訴你到底該做些什么。
  　　
  　　Scrum 的強(qiáng)大和令人痛苦之處就在于你不得不根據(jù)自己的具體情況來對(duì)它進(jìn)行調(diào)整。
  　　
  　　產(chǎn)品 backlog是 Scrum的核心，也是一切的起源。從根本上說，它就是一個(gè)需求、或故事、或特性等組成的列表，按照重要性的級(jí)別進(jìn)行了排序。它里面包含的是客戶想要的東西，并用客戶的術(shù)語(yǔ)加以描述。
•   　　印刷很華麗，書也很小，頁(yè)數(shù)也不多，不過里面沒有什么廢話，也沒有讓人暈頭轉(zhuǎn)向的哲學(xué)式的辯證方法。全部都是實(shí)踐，真刀真槍干出來的經(jīng)驗(yàn)。很不錯(cuò)的一本書，讓我以最快的方法認(rèn)識(shí)什么是scrum，而且怎么來實(shí)現(xiàn)scrum，看完它準(zhǔn)備再scrum敏捷項(xiàng)目管理
•   　　
  　　分了兩段時(shí)間，但是算是一口氣讀完了這本書。很喜歡前面的序，特別是風(fēng)清揚(yáng)的那段話。
  　　如今，敏捷開發(fā)確實(shí)收到很多企業(yè)的推崇，算是一個(gè)小潮流。但是多數(shù)團(tuán)隊(duì)使用敏捷的初衷都是又敏又捷，又快又爽。
  　　這本書確實(shí)可以作為一本入門教材，不僅僅是因?yàn)樗?，文字翻譯后通俗易懂，而且他也著實(shí)符合了敏捷的經(jīng)濟(jì)學(xué)思想。雖說只是作者的所做所感，每一個(gè)環(huán)節(jié)又符合了敏捷的方法論及業(yè)界通用的流程。
  　　
  　　但敏捷也沒有固定的流程和方法，因此作者也沒做太多贅述，但是忘記所有的方法和流程之前也確實(shí)需要先做一遍，才能整理出適合本團(tuán)隊(duì)的符合經(jīng)濟(jì)學(xué)的方法。符合風(fēng)清揚(yáng)的學(xué)完就忘。
•   　　這本書很不錯(cuò)，輕松簡(jiǎn)單的帶你進(jìn)入Scrum之門，了解實(shí)施Scrum的一些實(shí)踐。不想買的可以在InfoQ下載：http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches
  　　萬惡的資本家原來想用高度自動(dòng)化的工具把軟件這個(gè)行業(yè)推向流水線生產(chǎn)，把本來已經(jīng)杯具的代碼工變成《摩登時(shí)代》里扭螺絲的餐具，慢慢發(fā)現(xiàn)此路不通，至少在可預(yù)見的未來不通，當(dāng)然也可能是發(fā)現(xiàn)成本太高劃不來，像中國(guó)的建筑業(yè)一樣層層包工才是王道？不過再怎么組件化低耦合，代碼還是要有人寫的，只好施展人文關(guān)懷，提高代碼工的積極性，加強(qiáng)主人翁教育，這不正好符合社會(huì)*主……義先進(jìn)性，我們從小就知道自己是主人，這一次要抓住機(jī)會(huì)跟包公討要尊嚴(yán)。v5的Celestial Empire老板會(huì)給你這樣的機(jī)會(huì)嗎，在他們猶豫的時(shí)候發(fā)現(xiàn)還有Scrum master，這就好辦了，這不“中國(guó)敏捷軟件開發(fā)聯(lián)盟”浩浩蕩蕩成立了（http://tech.163.com/10/1213/22/6NQL8IFV000915I3.html），想造反？先問問咨詢的認(rèn)證的去。
  　　閑話扯完，希望不是又吹起一個(gè)認(rèn)證的泡泡。
  　　還有，如果未來流水線了開數(shù)控的會(huì)比擰螺絲的賺，如果未來層層插件組裝了，大包工頭比小包工頭賺，開個(gè)挖土機(jī)或者拉土車自由職業(yè)比搬磚頭賺，所以在工作之余還是得多學(xué)習(xí)多看書，未來別落后。
•   　　這本書的實(shí)用不用我來廢話了。我的team已經(jīng)使用scrum有段時(shí)間了，今天我又重讀了部分章節(jié)，現(xiàn)在是一個(gè)根據(jù)我的個(gè)人經(jīng)驗(yàn)，反思我所在team的scrum實(shí)踐所存在的不足。
  　　1. 我們混淆了backlog的真正意義，他是產(chǎn)品負(fù)責(zé)人提出的，從業(yè)務(wù)角度出發(fā)的，可以demo的故事；但是我們的往往是開發(fā)人員根據(jù)項(xiàng)目需要所列舉的要做的事情。我們需要進(jìn)一步區(qū)分故事和任務(wù)。
  　　2. 我們的sprint planning meeting并不規(guī)范，并不排每個(gè)故事的priority，而且花了太多時(shí)間在討論how to design and how to implement,因此常常超時(shí)。
  　　3. 每日例會(huì)對(duì)于昨天干了什么更看重，但更應(yīng)側(cè)重今天打算干什么。
  　　
  　　但也有他沒有很好解決的問題，比如“技術(shù)故事”，舉個(gè)例子，“重構(gòu)現(xiàn)有代碼”，這些東西沒法demo或者交付，而且優(yōu)先級(jí)比項(xiàng)目的進(jìn)度看起來更低，如何把他添加到backlog列表中，這是個(gè)值得思考的問題。
  　　
  　　我很關(guān)心的測(cè)試問題，還需要再重讀一下，看看作者是怎么做的。
•   　　Scrum因?yàn)檎惺缴?，?shí)踐性強(qiáng)而受到推崇——把一個(gè)漫長(zhǎng)無法預(yù)計(jì)項(xiàng)目開發(fā)映射到橄欖球簡(jiǎn)短的招式。跟傳統(tǒng)的里程碑不一樣，sprint 就是沖刺，基于時(shí)間的沖刺，里程碑周期會(huì)長(zhǎng)檢驗(yàn)結(jié)果，而Scrum周期短容易調(diào)整，并且Scrum檢驗(yàn)效率，而非孤立的結(jié)果。 效率高了結(jié)果就當(dāng)然更好。
•   　　這本書從始至終都實(shí)實(shí)在在、原原本本的介紹自己的scrum實(shí)踐過程，有經(jīng)驗(yàn)、有教訓(xùn)。對(duì)于任何想實(shí)施敏捷開發(fā)過程的團(tuán)隊(duì)都有借鑒意義，小到會(huì)議時(shí)間、地點(diǎn)、會(huì)議紀(jì)要怎么寫，大到測(cè)試怎么做。
  　　下面是我的讀書筆記：
  　　http://www.lixinyang.com/2009/10/15/scrum-xp/
  　　
•   　　這本書是一口氣看完的, 字里行間都能夠體會(huì)到硝煙彌漫.
  　　
  　　感覺這本書更像是一種CookBook, Scrum 是一種靈活的框架, 它沒有那么多的繁文縟節(jié), 在每一個(gè)不同的team里, 在同一個(gè)team的不同項(xiàng)目中, Scrum都在演變, 都在進(jìn)化.
  　　
  　　我覺得在眾多的Scrum文章和書籍中,真的缺少這種詳細(xì)的像實(shí)戰(zhàn)報(bào)告一樣的東西. 我現(xiàn)在所處的環(huán)境不能實(shí)施Scrum, 因此有很多的實(shí)際經(jīng)驗(yàn)是無法得知的, 這本書正好彌補(bǔ)了這個(gè)我在學(xué)習(xí)Scrum中的缺陷. 盡管還會(huì)有很多的不解, 但是這種從實(shí)際中來的經(jīng)驗(yàn)對(duì)于學(xué)習(xí)Scrum來說已經(jīng)是相當(dāng)寶貴了.
•   　　首先，個(gè)人覺得這是一本不錯(cuò)的小書。
  　　
  　　說它小，是因?yàn)檫@本書很薄，100多頁(yè)吧，無非就是程序開發(fā)那點(diǎn)事。說它不錯(cuò)，是因?yàn)樗軐?shí)用，沒什么花哨的東西。
  　　
  　　其次，這是一本scrum的實(shí)施指南。
  　　
  　　周圍的很多程序員，看了太多的敏捷的思想，聽了太多的敏捷的原則，xp、scrum、sprint更是耳熟能詳，我想，我們?nèi)鄙俚恼沁@樣一本現(xiàn)實(shí)中的敏捷開發(fā)指南。
  　　
  　　從制定backlog（user story），再到制定sprint計(jì)劃（iteration），任務(wù)跟蹤，開發(fā)間布置，如何開早會(huì)，如何測(cè)試等等，你會(huì)發(fā)現(xiàn)，本書描寫的是項(xiàng)目開發(fā)中的那些最最平常，卻又最最重要的事情。
  　　
  　　如果你沒有參與過敏捷開發(fā)，那么看本書，可以讓你了解敏捷開發(fā)在項(xiàng)目的過程中到底是怎樣實(shí)施的，我想這比空洞的說教要有用的多。
  　　
  　　如果你正在參與到敏捷開發(fā)中，那么看本書，至少可以讓你了解別的團(tuán)隊(duì)，別人是如何實(shí)施敏捷開發(fā)的，從中我們收獲什么樣的經(jīng)驗(yàn)和教訓(xùn)。
  　　
  　　最后，基于國(guó)內(nèi)的情況，書中的一些方式我們可能無法實(shí)施，不過，我認(rèn)為依然可以從中學(xué)到很多東西，從而進(jìn)一步理解敏捷開發(fā)的實(shí)質(zhì)和敏捷開發(fā)的應(yīng)用哲學(xué)。
  　　
  　　OK，不多說了，just read it！
•   　　按部就班的正統(tǒng)流程如CMM注重評(píng)審，會(huì)議，周報(bào)。表面上是通過制度保障質(zhì)量，深層次上也是營(yíng)造交流的機(jī)制和環(huán)境。
  　　
  　　SCRUM，或者說XP等敏捷方法雖然倡導(dǎo)了無設(shè)計(jì)，無文檔的開發(fā)流程，但在充分交流這條路上走得更徹底：
  　　
  　　 * 結(jié)對(duì)編程是開發(fā)人員之間的強(qiáng)制交流
  　　 * 客戶代表是開發(fā)人員與需求提出方的強(qiáng)制交流
  　　 * 持續(xù)集成是整個(gè)項(xiàng)目組開發(fā)人員的強(qiáng)制交流
  　　 * SCRUM中每次sprint計(jì)劃會(huì)議，也是多方--需求方，管理者，開發(fā)人員的強(qiáng)制交流，最終的計(jì)劃是多方意志妥協(xié)的結(jié)果。
  　　
  　　...
  　　
  　　http://blog.duofish.cn/articles/8%E6%9C%88%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E2%80%94%E2%80%94%E3%80%8Adreaming-in-code%E3%80%8B%E5%92%8C%E3%80%8A%E7%A1%9D%E7%83%9F%E4%B8%AD%E7%9A%84scrum%E5%92%8Cxp%E3%80%8B.html
•   　　我所在公司是個(gè)百年名企，和很多startup company相比，組織結(jié)構(gòu)龐大臃腫，headcount絕對(duì)超過150法則所建議的神奇數(shù)字150（該法則認(rèn)為將組織規(guī)模控制在150人以下命令才得以執(zhí)行團(tuán)體才能良性互動(dòng)），而且凡事講究process，對(duì)客戶需求的response難免遲緩滯后，這在如今事事講究速度效率強(qiáng)調(diào)快速反應(yīng)的時(shí)代，這頭巨象的轉(zhuǎn)身自然不如土狼迅捷靈敏，尤其在行業(yè)利潤(rùn)日益稀薄的大趨勢(shì)下，在各方豪杰名士土狼的環(huán)伺下，市場(chǎng)占有率，競(jìng)爭(zhēng)力自然今非昔比。大概也是基于此，公司上層才會(huì)積極擁抱各類新概念，掀起一輪又一輪項(xiàng)目管理執(zhí)行的evolution, revolution罷，可惜，往往是形似神不似。
  　　
  　　Recently when I have still suffered the deployment of streamline development and doubted the benefits of it, there comes a new strategy to pilot and deploy agile in our project management. Sure, It is trendy that everybody talking about the agile and scrum. But what agile really is? How to scrum? How to adapt to this new concept, new way of working? How big benefit it will bring to our company? What are the obstacles we face? There is still no clear answer. We all are just learning when we swim.
  　　
  　　This book can be viewed as good practices, I really learn something from this book, at least, not in theoretical level while combined abstract noun/theory with concrete example in reality. When I finished reading, I am clearer about agile and scrum. However, here I don’t want to get into the details what and how I learn from this book, how good this book is. I just select some interesting jargons from this book, I heard them somewhere else previously. In order to know them more: background, origin, story and meaning etc, I google them to get deeper understanding. You can view it as “買櫝還珠”: I buy the glittering casket and return the pearls to the seller. I don’t care to be a modern version of 楚人。
  　　
  　　Yesterday’s weather:
  　　This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community. It is technique to make our future plans based on what we know.
  　　Origin: Some country decides to build a sophisticated computer system to predict the weather. After spending more money than people can imagine, they come up with wonderful result - and proudly claim that the system is 70% accurate. Somebody then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.
  　　The point of course is that while Yesterdays Weather is a crude mechanism, it ends up being not significantly less accurate than more sophisticated (i.e. complicated) ways of doing it.
  　　
  　　“Chickens and Pigs” metaphor:
  　　It comes from the idea of a project to make breakfast of bacon and eggs. The Chicken suggests that the two involve themselves in a scheme making breakfast of bacon and eggs. In reply, the Pig always notes that, for the Chicken, only a contribution is required as a chicken can simply lay an egg and then resume normal activities, while for the Pig a "total commitment" (or total sacrifice) is needed as in order to make ham or bacon, the pig must be slaughtered. This example simply illustrates that being involved may mean being a participant with little or no effort, while being committed takes time and energy, and means much more than just being involved.
  　　
  　　This fable is commonly referenced in the Agile software development community to illustrate two types of project members: pigs, who are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.
  　　
  　　Gut feeling:
  　　A feeling that you are certain is right, even if you cannot explain why.
  　　
•   　　140多頁(yè)，一天看完。
  　　不虧是一本介紹scrum實(shí)施的書，寫法也很實(shí)踐，很敏捷。
  　　
  　　我很喜歡sprint on the wall的方式，簡(jiǎn)單明了，比再先進(jìn)的online app都來得爽快。非常適合集中式的開發(fā)，不過這樣對(duì)辦公室也有了一定成都的要求 ;)
•   　　非常不錯(cuò)的一本書。
  　　
  　　關(guān)于敏捷方法的理論和介紹，可以說已經(jīng)要汗牛充棟了，目前被人們廣泛承認(rèn)的敏捷方法也有一定的數(shù)量了。但是如何去敏捷，也許一千個(gè)組織有一千種各自迥異的實(shí)踐方式。
  　　
  　　沒有哪一種敏捷實(shí)踐告訴你要完全按照它所描述的章章條條照本宣科，也沒有哪個(gè)組織所實(shí)施的敏捷實(shí)踐會(huì)是銀彈，更不用說是放之四海皆準(zhǔn)的最佳時(shí)間。
  　　
  　　那么這本書有什么意義呢？很廢話的說一句當(dāng)然有。作者Henrik Kniberg通過告訴你他們?nèi)绾螌?shí)踐敏捷，具體來說就是最為流行的Scrum和XP這兩個(gè)實(shí)踐，給了讀者一個(gè)敏捷方法在現(xiàn)實(shí)項(xiàng)目中實(shí)施的借鑒，從而為讀者帶來思考，如果自己的項(xiàng)目要實(shí)施敏捷，具體該怎么做。
•   嗯。作者馬上要到清華園開會(huì)鳥。。你去不去？
•   @欒楚
  你說的是譯者，還是原著？
  我猜下應(yīng)該是譯者吧，infoQ組織的那個(gè)嗎？
•   10號(hào)開始5級(jí)正式評(píng)估了，現(xiàn)在回頭來看，覺得CMMI一點(diǎn)也不注重流程，流程是你自己的，它完全不在乎你如何運(yùn)作，給你的是目標(biāo)，是建議，僅此而已。當(dāng)你達(dá)到五級(jí)時(shí)，CMMI想要看到的，是你們已經(jīng)建立的數(shù)據(jù)化的持續(xù)改進(jìn)機(jī)制，然后瘋查你的分析方法和數(shù)據(jù)收集。
  交流是好的，是被建議的，但不是必須的，至少在CMMI來說。從這個(gè)角度來看，six sigma和 QC更為純粹。情感上，我個(gè)人偏向于QC。
•   汗，大哥你讀英文的速度還真是夠快的，我零散但認(rèn)真看了幾天了，目前才看了一半左右。。。。
•   我只挑了幾張讀阿，比如如何管理地址分布的團(tuán)隊(duì)就不看，因?yàn)槲蚁虢⒁粋€(gè)集中式團(tuán)隊(duì)，如何融入xp也不看，因?yàn)檫€做不到，慢慢來 ;)
•   這書不錯(cuò)，我也剛看完：
  http://www.cnblogs.com/yuandong/archive/2008/06/19/Read_Scrum_and_XP_from_the_Trenches.html
•   非常不錯(cuò)的書，我得努力提高下自己的閱讀速度

相關(guān)圖書

• 棒球大聯(lián)盟(55)
• 蒼河白日夢(mèng)
• 棒球大聯(lián)盟(54)
• 棒球大聯(lián)盟(53)
• 棒球大聯(lián)盟(52)
• 棒球大聯(lián)盟(51)
• 棒球大聯(lián)盟(48)
• 全國(guó)計(jì)算機(jī)等級(jí)考試教程
• 小學(xué)數(shù)學(xué)口算速算訓(xùn)練營(yíng)
• 全國(guó)計(jì)算機(jī)等級(jí)考試教程
• 新大綱全國(guó)計(jì)算機(jī)等級(jí)考試教程
• 全國(guó)計(jì)算機(jī)等級(jí)考試教程
• Google成功背后的技術(shù)
• .NET程序員面試指南
• 棒球大聯(lián)盟(02)
• 棒球大聯(lián)盟(03)
• 現(xiàn)代企業(yè)涉稅會(huì)計(jì)處理與納稅籌劃技巧
• 棒球大聯(lián)盟(04)
• 棒球大聯(lián)盟(05)
• 棒球大聯(lián)盟(06)
• 棒球大聯(lián)盟(07)
• 棒球大聯(lián)盟(08)
• 親親寶貝啟蒙書 動(dòng)物故事
• 親親寶貝啟蒙書 寓言故事
• 親親寶貝啟蒙書 美德故事