具體描述
産品特色
內容簡介
詳述用於估算和計劃任何敏捷項目的行之有效的技巧
《敏捷軟件開發實踐 估算與計劃 為對敏捷項目進行估算和計劃提供瞭緊貼實用的**指導方針。在本書中，敏捷聯盟聯閤創始人Mike Cohn討論瞭敏捷估算與計劃背後的哲學思想，並通過列舉現實世界的例子和項目案例具體展示瞭如何完成工作。本書絕對是你開發工具箱中必不可少的敏捷估算“利器”。
本書清晰地闡述瞭相關概念，並引導讀者逐步找到下列問題的答案：將構建什麼産品？産品規模多大？需要在何時完成？到那時我們到底能完成多少？你*先會認識到優秀的計劃由哪些要素組成，接著會瞭解到如何纔能使計劃敏捷化。
采用本書中講述的方法，你將獲得敏捷估算工具，幫助你從始至終保持敏捷、節省時間、充分利用資源並且完成更多工作。本書要點如下：
為什麼傳統的指令性計劃會失敗而敏捷計劃會取得成功
如何使用故事點和理想人天來預估特性的規模，以及它們分彆適用於哪種情形
重設估算的方式和時機
如何同時采用財務及非財務手段來確定特性的優先級
如何將大的特性分解為更小的、更便於管理的特性
如何計劃迭代周期並對團隊的初始進度進行預估
如何安排具有高度不確定性或進度相關風險的項目的進度
如何對由多個團隊閤作開發的項目進行估算
本書介紹所有敏捷、半敏捷或者迭代流程，包括Scrum、XP、特性驅動的開發、水晶方法、自適應軟件開發、DSDM、統一過程(UP)以及其他許多方式。它無疑是每位研發經理、團隊經理和成
員不可或缺的寶貴資源。
作者簡介
Mike Cohn，是專注於流程與項目管理的谘詢與培訓公司Mountain Goat Software的創始人。Mike擁有逾20年的行業經驗，擔任過創業公司乃至財富40強企業的技術負責人，他還是敏捷聯盟的發起成員之一，經常在業界相關雜誌上發錶文章並齣席有關會議。他也是User Stories Applied (Addison-Wesley ，2004年齣版)一書的作者。
精彩書評
“你的項目進展順利嗎？對需求變更感到沮喪？前途未蔔？産品質量不佳，又延誤瞭截止期限？Mike Cohn*富洞察力，他清晰明瞭地展示瞭如何有效地開發具有卓越業務價值的軟件。通過閱讀本書，你可將精力專注於真正關鍵的行動，當環境條件變化時也將繼續如此。”
——Rick Mugridge，Rimu Research有限公司總監，Fit for Developing Software 的*一作者
“我們是本書所述敏捷方法的忠實信徒，通過實踐和持續采用這些方法，獲得瞭許多*其重要的積*影響。我強烈嚮有誌於使軟件開發更可行、更有效的所有讀者推*此書。”
——Mark M. Gutrich，Fast 401k公司總裁兼*席執行官
目錄
第Ⅰ部分 問題與目標
第1章 計劃的目的 3
1.1 為何要進行估算和計劃 4
1.1.1 減少風險 5
1.1.2 降低不確定性 5
1.1.3 提供更好的決策支持 5
1.1.4 建立信任 6
1.1.5 傳遞信息 6
1.2 優秀的計劃是什麼 7
1.3 敏捷計劃是什麼 7
1.4 小結 8
1.5 討論題 8
第2章 計劃失敗的原因 9
2.1 基於活動而不是基於特性進行計劃 9
2.1.1 活動不會提前完成 10
2.1.2 延誤沿著計劃錶嚮下傳遞 10
2.1.3 活動不是互相獨立的 11
2.2 多任務處理導緻更多的延遲 12
2.3 不按優先級開發特性 13
2.4 忽視瞭不確定性 13
2.5 把估算當作承諾 14
2.6 小結 14
2.7 討論題 15
第3章 敏捷方法 17
3.1 項目的敏捷開發方法 18
3.1.1 敏捷團隊作為一個整體工作 18
3.1.2 敏捷團隊按短迭代周期工作 19
3.1.3 敏捷團隊每次迭代交付一些成果 19
3.1.4 敏捷團隊關注業務優先級 20
3.1.5 敏捷團隊進行檢查和調整 21
3.2 敏捷計劃方法 21
3.2.1 計劃的不同層次 22
3.2.2 滿意條件 23
3.3 小結 25
3.4 討論題 25
第Ⅱ部分 估 算 大 小
第4章 使用故事點估算大小 29
4.1 故事點是相對的 29
4.2 速度 31
4.3 小結 33
4.4 討論題 33
第5章 使用理想人天進行估算 35
5.1 理想時間和軟件開發 36
5.2 以理想人天作為對大小的度量 37
5.3 給齣一個而不是多個估算值 37
5.4 小結 38
5.5 討論題 38
第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
精彩書摘
在故事點和理想人天之間進行選擇
——采用故事點進行估算
“If you tell people where to go，but not how to get there，you’ll be amazed at the
results.”
—— Ceneral George S.Patton
有利於故事點的考慮因素
● 故事點有助於驅動跨功能的行為
● 故事點估算不會過期
● 故事點是純粹對大小的度量
● 故事點估算通常更快
● 我的理想人天不等於你的理想人天
1.故事點有助於驅動跨功能的行為
敏捷團隊之所以會成功，一個原因在於這種團隊是跨功能的。也就是說，敏捷團隊包含瞭來自構建産品所需所有角色的成員，包括程序員、測試人員、産品經理、可用性設計師、分析師、數據庫工程師等。當我們首次建立一個跨功能的團隊時，有些成員往往可能很難放下他們的部門身份。而項目參與者需要首先把自己看成團隊成員，然後纔是專業貢獻者時，産品這樣纔能從中受益—— 也就是說，“我在進行Napa 項目，是一名測試人員”，而不是“我是一名測試人員，分配到瞭Napa 項目中”。兩者的區彆似乎微不足道，但在思維方式上的改變則並非如此微小。
用故事點進行估算可以幫助團隊學會跨功能工作。由於一個故事點估算應該是代錶整個團隊所有工作的單一數值，因此對故事點的估算可以開啓針對所涉及到的全部相關事情的高層次討論。另一方麵，對理想人天的估算經常涉及專業小組估算用戶故事中“他們的那部分”需要多少時間，然後把所有的這些原子估算纍加在一起。例如，程序員可能認為需要3 個理想人天，數據庫工程師認為需要1 天，而測試人員需要2 天。該故事就會分配6 個理想人天。
最早針對用戶故事的討論應該如何進行，在這一問題上的微小差異會對這個故事的開發方式産生持續影響。
2.故事點估算不會過期
以故事點方式進行的估算比以理想日進行的估算具有更長的“保質期”。因為團隊對技術、業務領域和他們自己的經驗不同，以及其他的一些因素，都會導緻以理想人天進行的估算發生變化。想要瞭解原因，假設一名程序員正在學習一門新語言，他被問及需要多少時間來開發一個小程序。他的答案可能會是5 天。過幾個月後，再問這個程序員開發一個完全相同大小和復雜度的程序需要多少時間。由於他對這門語言更為熟悉，他的答案可能會是1 天。現在我們就遇到瞭問題，兩個程序的大小完全一樣，但對它們的估算值不一樣。
我們希望經過一段時間，對速度的測量會糾正或者解決這個問題。但在這個例子中是行不通的。相反，雖然完成瞭更多的工作，我們仍會看到一個穩定的速度。假設這名程序員是開發小組中的唯一人員，他采用一周的迭代周期。他第一次開發這個程序的時候，會估算需要5 個理想日。我們假設在他所處的開發環境中，一天就相當於一個理想人天。他在迭代的第一天開始這個項目，在第五天結束。他在這次迭代中的速是5。幾個月以後，因為他把一個相似的程序估算為1 個理想人天，他將在一次迭代中完成5 個這樣的程序。他的速度還是5，雖然做的工作以前的5 倍。對某些項目，尤其是那些采用瞭新技術，或者團隊對應用領域並不熟悉的項目，這種現象會非常明顯。
需要注意，如果由於架構的開發導緻工作的大小發生瞭變化，故事點估算和理想人天
估算都應該更新。但是，如果隻是因為團隊對某些東西更為熟悉，則隻需修改理想人天
估算。
3 故事點是對大小的純粹度量
正如本章的引言部分所描述，當估算一件事需要多久時，重要的第一步是估算它的大小或者說需要做多少事情。故事點純粹是對大小的估算，而理想人天不是。理想人天可以被用作對大小的度量，但是存在一些不足。前一節中曾經強調，以理想人天做齣的估算會因為開發人員熟練程度的變化而改變。故事點不會齣現這個問題—— 大小就是那麼大，不會發生變化。這種不變性是任何對大小的度量都希望得到的特性。
故事點對大小的純粹度量帶來瞭兩個好處。首先，這意味著我們可以隻通過類比就進行估算。有一些可靠的證據錶明我們更善於估算“這個和那個差不多”而不是估算事物的絕對大小(Lederer and Prasad 1998；Vicinanza 1991)。另一方麵，當我們采用理想人天時，也可以用類比進行估算。但使用理想人天進行估算時，我們也傾嚮於考慮日程錶以及用戶故事需要多長的開發時間。
其次，由於故事點是對大小的純粹度量，完全是抽象的，因此不會受到把它們與現實進行比較的誘惑。而用理想人天進行估算的開發小組幾乎不可避免地會把他們的理想人天與現實人天進行比較。然後他們會發現要找齣理由說明自己為什麼在一次10 天的迭代中“隻”完成瞭8 個理想人天的工作。
4 故事點估算通常更快
用故事點進行估算的團隊看起來會比用理想人天進行估算的團隊進行得更快。在估算很多用戶故事的時候，都需要對故事進行高層次的設計討論：我們要在數據庫中實現它嗎？可以重用用戶界麵嗎？這對中間層有什麼影響？所有這些問題都會在某個時候湧現齣來。
我的經驗是用理想人天進行估算的團隊有一種傾嚮，他們對這些問題的討論會比用故事點進行估算的團隊更深入一些。這個差異隻是推測齣來的，因為用理想人天進行估算的時候，更容易會考慮開發一個用戶故事所需完成的各項任務，而不是從這個故事相對其他故事的大小這個角度來考慮。
5 我的理想人天不等於你的理想人天
假設有兩個跑步者，一個跑得快一個跑得慢，他們一起站在一條小路的起點。兩人都可以看到小路的全程，而且都認為它有1 公裏長。他們可以把它與另一條他們都跑過的路進行比較，而且都認為它大約是那條路的一半長度。這種對道路尺寸(實際上在這個例子中是距離長度)的討論是很有意義的。
假設兩個跑步者討論的是跑這些路所需要的時間而不是討論它們的長度。跑得快的人會說：“這是一條5 分鍾的路。”跑得慢的人的迴答會是：“不對，這條路至少是8 分鍾。”兩個人當然都是對的，但他們沒辦法解決這個差異，除非同意按照其中一個人跑完這條路需要的時間(或者另一個人需要的)來討論。
使用理想人天時會齣現同樣的問題。你可能會認為你可以在3 個理想人天內完全開發一個特定的用戶故事。我認為我可以在5 天內完成。我們可能都是對的但如何達成一緻？如果我們認為你將是完成這項工作的人，我們也許會選擇使用你的估算。但是這也許會是一個錯誤，因為等到我們實際上處理這項工作的時候，你可能太忙瞭，因此需要我來完成它，而我就會推遲完成，因為對它的估算值是你所需要的3 天，但是我實際上需要5 天。大多數團隊的做法是忽略這個問題。如果所有開發人員的水平大緻相當或者程序員總是結對工作(in pair)，就可以抵消生産效率上的極端差異，忽略這個問題的做法就是可以接受的。
前言/序言
本書本來被命名為《估算與計劃敏捷項目》。不過，書名最終確定為《敏捷軟件開發實踐 估算與計劃》。兩者的差異似乎微不足道，但實際上並非如此。現在的書名明確瞭估算和計劃過程本身就應該是敏捷的。不采用敏捷估算和計劃，項目就不可能是敏捷的。
本書的大部分內容是關於計劃，我把它看作是用來迴答“我們要構建什麼以及何時完成？”這一問題。但是，要迴答關於計劃的問題，我們還必須解決關於估算(“它的規模有多大？”)和進度安排(“什麼時候能完成？”和“我到那時能得到多少？”)的問題。
本書由7個部分共23章組成。每一章的結尾都有對該章重點的小結和一組討論題。由於估算和計劃應該是整個團隊的工作，因此我希望對本書的閱讀方式是團隊成員每周聚在一起，對看過的內容以及每章結尾的討論題進行討論。由於敏捷軟件開發在全世界都受到歡迎，因此盡可能避免讓本書顯得過分以美國為中心。為瞭達到這一目的，我使用瞭一種通用的貨幣單位，將金額寫作500“幣”，而不是500美元或者500歐元。
本書的第I部分介紹瞭計劃為什麼重要、我們常會遇到的問題，以及敏捷方法的目標。第1章是本書的起始，介紹瞭計劃的目的、一個優秀的計劃由哪些部分組成，以及什麼纔是敏捷計劃。第2章中介紹瞭為什麼傳統估算和計劃方法是導緻結果難以令人滿意的最重要原因。最後，第3章首先簡要地重述瞭敏捷的含義，然後概括介紹瞭本書其他部分在不同層次上所采取的敏捷估算和計劃方法。
本書的第II部分介紹瞭估算的一個主要原則，即對大小和時間長度的估算應該相互獨立。第4和第5章介紹瞭兩個適用於對要開發的特性大小進行估算的計算單位：故事點和理想人天。第6章講述瞭采用故事點和理想人天進行估算的技巧，並包括瞭對計劃撲剋的介紹。第7章講述瞭何時以及如何進行重新估算。第8章則提供瞭有關如何在故事點和理想人天之間進行選擇的建議。
第III部分“為價值進行計劃”提供的建議告訴項目團隊如何確認他們正在構建盡可能好的産品。第9章介紹瞭在確定特性的優先級時需要綜閤考慮的一些因素。第10章展示瞭對特性或特性集閤的財務迴報進行建模的一種方法，以及如何對財務迴報進行比較以便開發團隊首先處理最具價值的特性。第11章主要講述有關如何評估産品用戶對各個特性的需求程度並確定其優先級的建議。第12章對本部分進行總結，給齣瞭一些建議，幫助將大的特性分解成更小的、更易管理的特性。
在第IV部分中，我們將注意力轉移到瞭有關項目時間進度安排的方麵。第13章首先討論瞭對一個相對簡單的、單一開發團隊的項目安排進度錶時所涉及的步驟。第14章討論瞭如何製定迭代的計劃。第15章和第16章討論瞭如何選擇閤適的迭代周期長度以及如何估算開發團隊的初始速率。第17章詳述瞭如何安排一個具有很高不確定性的或是在時間進度上很可能齣錯的項目的進度錶。第18章是這一部分的結尾，講述瞭對由多個團隊共同開發的項目進行估算和計劃所必需的其他步驟。
一旦建立瞭計劃，團隊就必須和整個公司的其他部門進行交流，並根據計劃進度對開發團隊的進度進行監督。這是第V部分的3章的主要內容。第19章主要關注對發布計劃進行監督，而第20章關注對迭代計劃進行監督。這一部分的最後一章，第21章主要解決如何就計劃及其進度進行溝通。
第22章是第VI部分唯一的一章。這一章與第2章講述的“為什麼傳統方法會失敗”相對照，討論瞭為什麼敏捷估算和計劃方法會有效。
第VII部分是全書的最後一部分，也隻有一章。第23章是一個展開的案例分析，以小說的形式重述瞭本書的重點。
用戶評價
這本書的封麵設計很吸引人，那種簡潔的綫條和漸變的色彩，一下子就抓住瞭我的眼球。我本來就是一名軟件開發者，日常工作離不開各種項目管理和開發流程。最近對敏捷開發的方法論特彆感興趣，市麵上也看瞭不少相關的書籍，但很多要麼過於理論化，要麼就隻是簡單羅列一些概念，真正能夠落地執行的指導性內容卻不多。當我看到這本書的書名時，第一反應就是它似乎正是我所需要的。特彆是“估算與計劃”這幾個字，這兩個環節在敏捷開發中絕對是重中之重，也是很多團隊感到頭疼的地方。我希望這本書能夠深入淺齣地講解如何進行有效的估算，比如用戶故事點估算、撲剋牌估算等，並且能夠提供切實可行的計劃製定方法，幫助我們更好地把握項目進度，管理團隊預期。我特彆期待書中能有具體的案例分析，讓我看到這些理論是如何在實際項目中應用的，以及如何規避常見的誤區。同時，如果書中能分享一些自動化估算和計劃的工具或技巧，那更是錦上添花，能夠極大地提高我的工作效率。總而言之，我對這本書充滿瞭期待，希望能從中獲得實實在在的知識和技巧，應用於我的日常開發工作中。
評分作為一名項目經理，我一直在尋找能夠幫助我提升團隊協作效率和項目交付質量的方法。敏捷開發的概念我已經有所瞭解，但如何將這些概念轉化為實際行動，尤其是在項目的初期估算和中期計劃調整方麵，一直是我的一個痛點。這本書的書名《敏捷軟件開發實踐：估算與計劃》讓我眼前一亮，它精準地切中瞭敏捷開發中最具挑戰性的兩個環節。我迫切地希望這本書能夠提供一套係統化的方法論，指導我如何帶領團隊進行準確的項目估算，如何有效地分解需求，以及如何製定齣靈活且可執行的項目計劃。我特彆關注書中關於如何處理需求變更、如何管理項目風險，以及如何平衡估算精度和開發速度的內容。我相信，如果這本書能夠提供一些實操性的工具和模闆，比如故事點估算卡片、迭代計劃錶等，將會極大地幫助我提升工作效率，並更好地與團隊和客戶溝通。我希望這本書不僅僅是理論的講解，更重要的是能夠提供可復製的實踐經驗，讓我能夠直接應用到實際工作中，解決我目前麵臨的睏境。
評分我是一名初入軟件行業的學生，對敏捷開發充滿瞭好奇，也知道估算和計劃是項目成功的重要基石。這本書的書名《敏捷軟件開發實踐：估算與計劃》讓我覺得它可能是一本非常適閤我入門的書籍。我希望這本書能夠用非常通俗易懂的語言，解釋敏捷開發的核心理念，特彆是關於估算和計劃的部分。例如，我想知道如何理解“估算”在敏捷開發中的意義，它和傳統開發中的“精確預測”有什麼區彆？我希望書中能夠詳細講解各種估算方法，比如用戶故事點、時間估算，以及它們各自的優缺點。同時，我也想學習如何根據估算結果來製定迭代計劃，如何進行任務分解，以及如何預估開發周期。如果書中能夠提供一些圖示和實例，幫助我理解這些概念，那就更好瞭。我特彆希望這本書能夠指導我如何培養敏捷思維，如何用一種更加靈活和適應性的方式去麵對項目中的不確定性。這本書對我來說，不僅僅是學習知識，更是培養一種解決問題的能力。
評分我是一名曾經參與過多個大型軟件項目的項目負責人，但近來對敏捷開發模式産生瞭濃厚的興趣，並希望將這種模式引入我的團隊。在過往的項目中，我們常常在項目初期花費大量時間進行詳盡的計劃，但隨著需求的不斷變化，這些計劃往往變得難以執行，導緻項目陷入睏境。因此，我認為《敏捷軟件開發實踐：估算與計劃》這本書的書名恰好戳中瞭我們目前最迫切的需求。我非常希望這本書能夠詳細闡述敏捷開發中，如何通過迭代和增量的方式進行估算，以及如何在不斷變化的環境中製定和調整項目計劃。我期待書中能夠提供一些具體的方法和工具，例如，如何有效地收集和梳理用戶故事，如何進行團隊自治的估算，以及如何在每個迭代結束後對計劃進行復盤和優化。我也希望書中能夠探討如何管理客戶的期望，以及如何通過透明的溝通機製，讓客戶理解並支持敏捷開發過程中的靈活性。這本書對於我來說，是尋求一種更高效、更具適應性的項目管理模式的關鍵。
評分我是一位有多年開發經驗的工程師，見過太多因為估算不準、計劃不閤理而導緻的項目延期和質量問題。敏捷開發的概念我接觸瞭不少，但總覺得在實踐中，尤其是在估算和計劃這兩個環節，還是存在很多灰色地帶。這本書的書名《敏捷軟件開發實踐：估算與計劃》似乎正是我一直在尋找的那種能夠填補我知識空白的書籍。我非常期待書中能夠深入探討如何利用敏捷原則來進行更準確、更可靠的項目估算。我希望書中能夠提供一些高級的估算技巧，比如如何處理技術債對估算的影響，如何考慮團隊成員的經驗和能力差異，以及如何處理模糊不清的需求。在計劃方麵，我更希望看到關於如何製定靈活的迭代計劃，如何應對突發情況，以及如何進行有效的進度跟蹤和風險管理。書中是否能夠提供一些關於如何構建健康的團隊文化，鼓勵透明溝通和持續改進的建議，來支持估算和計劃的有效執行，這也讓我非常感興趣。我希望這本書能夠提供一些能夠讓我眼前一亮的洞察，幫助我提升在估算和計劃方麵的專業能力。
評分學無止境，要嘗試和研究很多領域的知識
評分又要來評價瞭，這是標準的15字。
評分隻囤書不看書，僅僅隻是為瞭支持作者
評分618囤書啦啦啦。
評分書還是不錯的，學到瞭很多新領域的知識，值得推薦給大傢！
評分書還是不錯的，學到瞭很多新領域的知識，值得推薦給大傢！
評分京東品質還是不錯的，送貨快，售後好，會員P也還可以。
評分學校老師要求買的書，不管你們懂不懂反正我是看不懂。
評分還可以的。隨意買瞭幾本書。留著有空時候看看。
相關圖書
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 book.tinynews.org All Rights Reserved. 静思书屋 版权所有