具體描述
《敏捷軟件開發實踐 估算與計劃》中講述的方法采用，你將獲得敏捷估算工具，幫助你從始至終保持敏捷、節省時間、充分利用資源並且完成更多工作。
著者簡介
Mike Cohn是專門進行過程和項目管理谘詢與培訓的Mountain Goat Software公司的創始人。Mike擁有超過20年的行業經驗，擔任過從剛起步的新公司到財富40強企業的技術負責人，還是敏捷聯盟的發起成員之一。他經常在業界相關雜誌上發錶文章並齣席有關會議，也是User Stories Applied（Addison-wesley公司2004年齣版）一書的作者。
圖書目錄
第2章 計劃失敗的原因 9
第3章 敏捷方法 17
第4章 使用故事點估算大小 29
第5章 使用理想人天進行估算 35
第6章 估算方法 39
第7章 重估 49
第8章 在故事點和理想人天之間進行選擇 55
第9章 確定主題的優先級 63
第10章 確定經濟優先級 71
第11章 確定渴望度優先級 85
第12章 分解用戶故事 93
第13章 發布計劃精粹 103
第14章 迭代計劃 111
第15章 選擇迭代長度 127
第16章 估算速度 135
第17章 不確定性緩衝計劃 143
第18章 計劃多團隊項目 155
第19章 監督發布計劃 165
第20章 監督迭代計劃 173
第21章 關於計劃的溝通 179
第22章 敏捷計劃有效的原因 189
第23章 案例分析：Bomb Shelter Studio 197
· · · · · · (收起)
讀後感
简直是逼死强迫症的节奏。 字号，斜体，行间距用的之随性，中英文符号混用，运算符前后空格没有。 虽然内容和翻译都还不错，但强迫症真的要阵亡了。 整本书都在说计划，结果正体和斜体的计划感觉完全是乱搞的。 无图无真相…<图片4><图片3><图片2><图片1&...
評分从计划为何总是完不成谈起,引出敏捷开发的模式. 告诉你: 如何有效的评定需求的商业价值? 如何快速的执行迭代需求? 如何以平静的心态,娴熟的方法去迎接变化. 如何以"故事情节"来让大家的思想得以统一. ........................
評分刚读完三章，就想打五星了。 短短几章，把计划和估算目标说得有条有理，水到渠成地引入了对敏捷方法的介绍。既似曾相识，又耳目一新的感觉。 不过我会把它读完的，假如说后面的让人失望，我会把星星的级别再减下来。:P
評分刚读完三章，就想打五星了。 短短几章，把计划和估算目标说得有条有理，水到渠成地引入了对敏捷方法的介绍。既似曾相识，又耳目一新的感觉。 不过我会把它读完的，假如说后面的让人失望，我会把星星的级别再减下来。:P
用戶評價
補全瞭對項目周期最初的知識盲點，講的很清晰。排版令人發指。
评分乾貨比較多，但是例子太少，理論性太強。
评分乾貨比較多，但是例子太少，理論性太強。
评分即把本書當開發方法看，更把本書當做處理工作事務的方法論來看。基本原則體會如下： 1.越大型的工作越不要想著畢其功於一役，先拿六十分、用起來，在實踐中體會優勢與不足再行強化與完善，更容易找對方嚮。 2.三思而後行依然有道理，隻有對事務總體本質有瞭判斷和把握，纔能選齣高價值（高風險/低風險）的任務組成結構以高優先級進行推進落實，纔可能盡快拿到60分。 3.充份溝通，讓團隊上下對目標和難度有著大體相當的認知，上下同欲者勝！ 4.關鍵時點交付比為瞭完美交付更有意義，因為時間窗口可能稍瞬即逝，而完美其實無止盡。如果來不及，該砍還得砍。
评分我覺得估算要看到細節，有點像架構實戰說的，最後還是用經驗這個詞吧，當然什麼具體的經驗纔是我們需要知道的而不是兩個字。正確的定義“完成”至關重要，敏捷的完成是交互用戶價值，絕不是寫好代碼。有點像看《目標》的時候的疑問，如果無法銷售齣去，也是沒有什麼用的。何況還有效率和創造力的矛盾
相關圖書
本站所有內容均為互聯網搜索引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.quotespace.org All Rights Reserved. 小美書屋 版权所有